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PREFACE 



The Intel 80386 is a high-performance 32-bit microprocessor. This manual provides complete 
hardware reference information for 80386 system designs. It is written for system engineers 
and hardware designers who understand the operating principles of microprocessors and 
microcomputer systems. Readers of this manual should be familiar with the information in 
the Introduction to the 80386 (Intel publication Order Number 231252). 



RELATED PUBLICATIONS 

In this manual, the 80386 is presented from a hardware perspective. Information on the 
software architecture, instruction set, and programming of the 80386 can be found in these 
related Intel publications: 

• 80386 Programmer s Reference Manual, Order Number 230985 

• 80386 System Software Writers Guide, Order Number 231499 

• 80386 Data Sheet, Order Number 231630 

The 80386 Data Sheet contains device specifications for the 80386. Always consult the most 
recent version of this publication for specific 80386 parameter values. 

Together with the 80386 Hardware Reference Manual, these publications provide a complete 
description of the 80386 system for hardware designers, software engineers, and all users of 
80386 systems. 



ORGANIZATION OF THIS MANUAL 

The information in this manual is divided into 12 chapters and three appendices. The material 
begins with a description of the 80386 microprocessor and continues with discussions of 
hardware design information needed to implement 80386 system designs. 

• Chapter 1, "System Overview." This chapter provides an overview of the 80386 and its 
supporting devices. 

• Chapter 2, "Internal Architecture." This chapter describes the internal architecture of 
the 80386. 

• Chapter 3, "Local Bus Interface." This chapter discusses the 80386 local bus interface. 
This chapter includes 80386 signal descriptions, memory and I/O organization, and local 
bus interface guidelines. 

• Chapter 4, "Performance Considerations." This chapter explores the factors that affect 
the performance of an 80386 system. 

• Chapter 5, "Coprocessor Hardware Interface." This chapter describes the interface 
between the 80386 and the 80287 and 80387 Numeric Coprocessors. Each of these copro- 
cessors expands the floating-point numerical processing capabilities of the 80386. 
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Chapter 6, "Memory Interfacing." This chapter discusses techniques for designing memory 
subsystems for the 80386. 

Chapter 7, "Cache Subsystems." This chapter describes cache memory subsystems, which 
provide higher performance at lower relative cost. 

Chapter 8, "I/O Interfacing." This chapter discusses techniques for connecting I/O devices 
to an 80386 system. 

Chapter 9, "MULTIBUS® I and 80386." This chapter describes the interface between 
an 80386 system and the Intel MULTIBUS I multi-master system bus. 

Chapter 10, "MULTIBUS® II and 80386." This chapter describes the interface between 
an 80386 system and the Intel MULTIBUS II multi-master system bus. 

Chapter 11, "Physical Design and Debugging." This chapter contains recommendations 
for constructing and debugging 80386 systems. 

Chapter 12, "Test Capabilities." This chapter describes 80386 test procedures. 

Appendix A contains descriptions of the components of the basic memory interface 
described in Chapter 6. 

Appendix B contains descriptions of the components of the 80387 emulator described in 
Chapter 5. 

Appendix C contains descriptions of the components of the dynamic RAM subsystem 
described in Chapter 6. 
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Customer Support is Intel's complete support service that provides Intel customers with Customer 
Training, Software Support and Hardware Support. 

After a customer purchases any system hardware or software product, service and support become 
major factors in determining whether that product will continue to meet a customer's expectations. 
Such support requires an international support organization and a breadth of programs to meet a 
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Software Support Service provides maintenance on software packages via software support contracts 
which include subscription services, information phone support, and updates. Consulting services can 
be arranged for on-site assistance at the customer's location for both short-term and long-term needs. 
For complex products such as NDS II or PICE, orientation/ installation packages are available 
through membership in Insite User's Library, where customer-submitted programs are catalogued and 
made available for a minimum fee to members. For more information contact your local Intel Sales 
Office. 
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programming languages, etc. For more information on these classes contact the Training Center nearest 
you. 

TRAINING CENTER LOCATIONS 

To obtain a complete catalog of our workshops, call the nearest Training Center in your area. 



Boston 

Chicago 

San Francisco 

Washington, D.C. 

Israel 

Tokyo 

Osaka (Call Tokyo) 

Toronto, Canada 



(617)692-1000 

(312)310-5700 

(415)940-7800 

(301)474-2878 

(972)349^91-099 

03^37-6611 

03-437-6611 

(416)675-2105 



London 

Munich 

Paris 

Stockholm 

Milan 

Benelux (Rotterdam) 

Copenhagen 

Hong Kong 



(0793) 696-000 
(089) 5389-1 
(01)687-22-21 
(468)734-01-00 
39-2-82-44-071 
(10)21-23-77 
(1) 198-033 
5-215311-7 



System Overview 



CHAPTER 1 
SYSTEM OVERVIEW 



The 80386 is a new 32-bit microprocessor that forms the basis for a high-performance 
32-bit system. The 80386 incorporates multitasking support, memory management, pipeUned 
architecture, address translation caches, and a high-speed bus interface all on one chip. The 
integration of these features speeds the execution of instructions and reduces overall chip 
count for a system. Paging and dynamic data bus sizing can each be invoked selectively, 
making the 80386 suitable for a v^ide variety of system designs and user applications. 

While the 80386 represents a significant improvement over previous generations of micro- 
processors, substantial ties to the earlier processors are preserved. Softw^are compatibility at 
the object-code level is provided, so that an existing investment in 8086 and 80286 software 
can be maintained. New software can be built upon existing routines, reducing the time to 
market for new products. Hardware compatibility is preserved through the dynamic bus- 
sizing feature. 

The major components of an 80386 system and their functions are shown in Figure 1-1. 
Table 1-1 describes these components. 



1.1 MICROPROCESSOR 

The 80386 provides unprecedented performance. At 16 MHz, the 80386 is capable of 
executing at sustained rates of three to four million instructions per second, a speed compa- 
rable to that of most super minicomputers. This achievement is made possible through a 
state-of-the-art design that includes a pipelined internal architecture, address translation 
caches, and a high-performance bus. 

The 80386 features 32-bit wide internal and external data paths and eight general-purpose 
32-bit registers. The instruction set offers 8-, 16-, and 32-bit data types, and the processor 
outputs 32-bit physical addresses directly, for a physical memory capacity of four gigabytes. 

Table 1-1. 80386 System Components 



Component 


Description 


80386 Microprocessor 

80287 or 80387 Numeric Coprocessor 

82384 Clock Generator 

8259A Programmable Interrupt Controller 

82258 Advanced DMA 


32-bit high-performance microprocessor with on- 
chip memory management and protection 

Performs numeric instruction in parallel with 
80386; expands instruction set 

Generates system clock and RESET signal 

Provides interrupt control and management 

Performs direct memory controller access (DMA) 
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Figure 1-1. 80386 System Block Diagram 
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The 80386 has separate 32-bit data and address paths. A 32-bit memory access can be 
completed in only two clock cycles, enabling the bus to sustain a throughput of 32 megabytes 
per second (at 16 MHz). By making prompt transfers between the microprocessor, memory, 
and peripherals, the high-speed bus design ensures that the entire system benefits from the 
processor's increased performance. 

Pipelined architecture enables the 80386 to perform instruction fetching, decoding, execu- 
tion, and memory management functions in parallel. The six independent units that make- 
up the 80386 pipeline are described in detail in Chapter 2. Because the 80386 prefetches 
instructions and queues them internally, instruction fetch and decode times are absorbed in 
the pipeline; the processor rarely has to wait for an instruction to execute. 

Pipelining is not unusual in modern microprocessor architecture; however, including the 
memory management unit (MMU) in the on-chip pipeline is a unique feature of the 80386. 
By performing memory management on-chip, the 80386 eliminates the serious access delays 
typical of implementations that use off-chip memory management units. The benefit is not 
only high performance but also relaxed memory-access time requirements, hence lower system 
cost. 

The integrated memory management and protection mechanism translates logical addresses 
to physical addresses and enforces the protection rules necessary for maintaining task integ- 
rity in a multitasking environment. The paging function simplifies the operating-system 
swapping algorithms by providing a uniform mechanism for managing the physical structure 
of memory. 

Task switching occurs frequently in real-time multitasking or multiuser systems. To perform 
task switching efficiently, the 80386 incorporates special high-speed hardware. Only a single 
instruction or an interrupt is needed for the 80386 to perform a complete task switch. A 
16-MHz 80386 can save the state of one task (all registers), load the state of another task 
(all registers, even segment and paging registers if required), and resume execution in less 
than 16 microseconds (at 16 MHz). For less sophisticated task and interrupt handling, the 
latency can be as short as 3.5 microseconds (at 16 MHz). 



1.2 COPROCESSORS 

The performance of most applications can be enhanced by the use of specialized coproces- 
sors. A coprocessor provides the hardware to perform functions that would otherwise be 
performed in software. Coprocessors extend the instruction set of the 80386. 

The 80386 has a numeric coprocessor interface that can support one of two coprocessors: 
the 80387 or the 80287. For applications that benefit from high-precision integer and 
floating-point calculations, these numeric coprocessors provide full support for the IEEE 
standard for floating-point operations. Both the 80387 and 80287 are software compatible 
with the 8087, an earlier numeric coprocessor. At 16 MHz, the 80387 operates about eight 
times faster than a 5-MHz 80287. However, the 80287 is fast enough for many applications 
and is a cost-effective solution for many designs. The 80386 therefore offers the system 
designer the choice of low-cost or high-performance numeric solutions. 
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1.3 INTERRUPT CONTROLLER 

The 8259A Programmable Interrupt Controller manages interrupts for an 80386 system. 
Interrupts from as many as eight external sources are accepted by one 8259A; as many as 
64 requests can be accommodated by cascading several 8259A chips. The 8259A resolves 
priority between active interrupts, then interrupts the processor and passes a code to the 
processor to identify the interrupting source. Programmable features of the 8259A allow it 
to be used in a variety of ways to fit the interrupt requirements of a particular system. 

1.4 CLOCK GENERATOR 

The 82384 Clock Generator generates timing for the 80386 and its support components. 
The 82384 provides both the 80386 clock (CLK2) and a half-frequency clock (CLK) to 
indicate the internal phase of the 80386 and to drive 80286-compatible devices that may be 
included in the system. It can also be used to generate the RESET signal for the 80386 and 
other system components. Both CLK2 and CLK are used throughout this manual to describe 
execution times. 



1.5 DMA CONTROLLER 

A DMA (Direct Memory Access) controller performs DMA transfers between main memory 
and an I/O device, typically a hard disk, floppy disk, or communications channel. In a DMA 
transfer, a large block of data can be copied from one place to another without the interven- 
tion of the CPU. 

The 82258 Advanced DMA (ADMA) Controller offers four channels and provides all the 
signals necessary to perform DMA transfers. Other features of the 82258 are as follows: 

• Command chaining to perform multiple commands 

• Data chaining to scatter data to separate memory locations (separate pages, for example) 
and gather data from separate locations 

• Automatic assembly and disassembly to convert from 16-bit memory to 8-bit I/O, or 
vice versa 

• Compare, translate, and verify functions 

• The option to replace one of the four high-speed channels with as many as 32 lower-speed, 
multiplexed channels. 
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CHAPTER 2 
INTERNAL ARCHITECTURE 



The internal architecture of the 80386 consists of six functional units that operate in 
parallel. Fetching, decoding, execution, memory management, and bus accesses for several 
instructions are performed simultaneously. This parallel operation is called pipelined 
instruction processing. With pipelining, each instruction is performed in stages, and the 
processing of several instructions at different stages may overlap as illustrated in 
Figure 2-1. The six-stage pipelined processing of the 80386 results in higher performance 
and an enhanced throughput rate over non-pipelined processors. 

The six functional units of the 80386 are identified as follows: 

• Bus Interface Unit 

• Code Prefetch Unit 

• Instruction Decode Unit 

• Execution Unit 

• Segmentation Unit 

• Paging Unit 
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Figure 2-1. Instruction Pipelining 
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The Execution Unit in turn consists of three subunits: 

• Control Unit 

• Data Unit 

• Protection Test Unit 

Figure 2-2 shows the organization of these units. This chapter describes the function of each 
unit, as well as interactions between units. 



2.1 BUS INTERFACE UNIT 

The Bus Interface Unit provides the interface between the 80386 and its environment. It 
accepts internal requests for code fetches (from the Code Prefetch Unit) and data transfers 
(from the Execution Unit), and prioritizes the requests. At the same time, it generates or 
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Figure 2-2. 80386 Functional Units 
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processes the signals to perform the current bus cycle. These signals include the address, 
data, and control outputs for accessing external memory and I/O. The Bus Interface Unit 
also controls the interface to external bus masters and coprocessors. 



2.2 CODE PREFETCH UNIT 

The Code Prefetch Unit performs the program look ahead function of the 80386. When the 
Bus Interface Unit is not performing bus cycles to execute an instruction, the Code Prefetch 
Unit uses the Bus Interface Unit to fetch sequentially along the instruction byte stream. 
These prefetched instructions are stored in the 16-byte Code Queue to await processing by 
the Instruction Decode Unit. 

Code prefetches are given a lower priority than data transfers; assuming zero wait state 
memory access, prefetch activity never delays execution. On the other hand, if there is no 
data transfer requested, prefetching uses bus cycles that would otherwise be idle. Instruction 
prefetching reduces to practically zero the time that the processor spends waiting for the 
next instruction. 



2.3 INSTRUCTION DECODE UNIT 

The Instruction Decode Unit takes instruction stream bytes from the Prefetch Queue and 
translates them into microcode. The decoded instructions are then stored in a three-deep 
Instruction Queue (FIFO) to await processing by the Execution Unit. Immediate data and 
opcode offsets are also taken from the Prefetch Queue. 



2.4 EXECUTION UNIT 

The Execution Unit executes the instructions from the Instruction Queue and therefore 
communicates with all other units required to complete the instruction. The functions of its 
three subunits are as follows: 

• The Control Unit contains microcode and special parallel hardware that speeds multiply, 
divide, and effective address calculation. 

• The Data Unit contains the ALU, a file of eight 32-bit general-purpose registers, and a 
64-bit barrel shifter (which performs multiple bit shifts in one clock). The Data Unit 
performs data operations requested by the Control Unit. 

• The Protection Test Unit checks for segmentation violations under the control of the 
microcode. 

To speed up the execution of memory reference instructions, the Execution Unit partially 
overlaps the execution of any memory reference instruction with the previous instruction. 
Because memory reference instructions are frequent, a performance gain of approximately 
nine percent is achieved. 
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2.5 SEGMENTATION UNIT 

The Segmentation Unit translates logical addresses into linear addresses at the request of 
the Execution Unit. The on-chip Segment Descriptor Cache stores the currently used segment 
descriptors to speed this translation. At the same time it performs the translation, the 
Segmentation Unit checks for bus-cycle segmentation violations. (These checks are separate 
from the static segmentation violation checks performed by the Protection Test Unit.) The 
translated linear address is forwarded to the Paging Unit. 

2.6 PAGING UNIT 

When the 80386 paging mechanism is enabled, the Paging Unit translates linear addresses 
generated by the Segmentation Unit or the Code Prefetch Unit into physical addresses. (If 
paging is not enabled, the physical address is the same as the linear address, and no 
translation is necessary.) The Page Descriptor Cache stores recently used Page Directory 
and Page Table entries in its Translation Lookaside Buffer (TLB) to speed this translation. 
The Paging Unit forwards physical addresses to the Bus Interface Unit to perform memory 
and I/O accesses. 
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CHAPTER 3 
LOCAL BUS INTERFACE 



Local bus Operations are considered in this chapter. The 80386 performs a variety of bus 
operations in response to internal conditions and external conditions (interrupt servicing, for 
example). The function and timing of the signals that make up the local bus interface are 
described, as well as the sequences of particular local bus operations. 

The high-speed bus interface of the 80386 provides high performance in any system. At the 
same time, the bus control inputs and status outputs of the 80386 allow for adaptation to a 
wide variety of system environments. 

The 80386 communicates with external memory, I/O, and other devices through a parallel 
bus interface. This interface consists of a data bus, a separate address bus, five bus status 
pins, and three bus control pins as follows: 

• The bidirectional data bus consists of 32 pins (D31-D0). Either 8, 16, 24, or 32 bits of 
data can be transferred at once. 

• The address bus, which generates 32-bit addresses, consists of 30 address pins (A3I-A2) 
and four byte-enable pins (BE3#-BE0#). Each byte-enable pin corresponds to one of four 
bytes of the 32-bit data bus. The address pins identify a 4-byte location, and the byte- 
enable pins select the active bytes within the 4-byte location. 

• The bus status pins establish the type of bus cycle to be performed. These outputs indicate 
the following conditions: 

Address Status (ADS#) — address bus outputs valid 
Write/Read (W/R#) — write or read cycle 
Memory /I/O (M/IO#) — memory or I/O access 
Data/Control (D/C#)— data or control cycle 
LOCK#— locked bus cycle 

• The bus control pins allow external logic to control the bus cycle on a cycle-by-cycle basis. 
These inputs perform the following functions: 

READY# — ends the current bus cycle; controls bus cycle duration 

Next Address (NA#) — allows address pipelining, that is, emitting address and status 
signals for the next bus cycle during the current cycle 

Bus Size 16 (BS16#) — activates 16-bit data bus operation; data is transferred on the 
lower 16 bits of the data bus, and an extra cycle is provided for transfers of more than 
16 bits 
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The following pins are used to control the execution of instructions in the 80386 and to 
interface external bus masters. The 80386 provides both a standard interface to communi- 
cate with other bus masters and a special interface support a numerics coprocessor. 

• The CLK2 input provides a double-frequency clock signal for synchronous operation. This 
signal is divided by two internally, so the 80386 fundamental frequency is half the CLK2 
signal frequency. For example, a 16-MHz 80386 uses a 32-MHz CLK2 signal. 

• The RESET input forces the 80386 to a known reset state. 

• The HOLD signal can be generated by another bus master to request that the 80386 
release control of the bus. The 80386 responds by activating the Hold Acknowledge 
(HLDA) signal as it relinquishes control of the local bus. 

• The Maskable Interrupt (INTR) and Non-Maskable Interrupt (NMI) inputs cause the 
80386 to interrupt its current instruction stream and begin execution of an interrupt service 
routine. 

• The BUSY#, ERROR#, and Coprocessor Request (PEREQ) signals make up the inter- 
face to an external numeric coprocessor. BUSY# and ERROR# are status signals from 
the coprocessor; PEREQ allows the coprocessor to request data from the 80386. The 
80386 can use either the 80287 or the 80387 coprocessor. 

All of the 80386 bus interface pins are summarized in Table 3-1. 



3.1 BUS OPERATIONS 

There are seven types of bus operations: 

Memory read 
Memory write 
I/O read 
I/O write 
Instruction fetch 
Interrupt acknowledge 
Halt/shutdown 

Each bus cycle is initiated when the address is valid on the address bus, and bus status pins 
are driven to states that correspond to the type of bus cycle, and ADS# is driven low. Status 
pin states that correspond to each bus cycle type are shown in Table 3-2. Notice that the 
signal combinations marked as invalid states may occur when ADS# is false (high). These 
combinations will never occur if the signals are sampled on the CLK2 rising edge when 
ADS# is low, and the 80386 internal CLK is high (as indicated by the CLK output of the 
82384). Bus status signals must be qualified with ADS# is true (low) to identify the bus 
cycle. 

Memory read and memory write cycles can be locked to prevent another bus master from 
using the local bus and allow for indivisible read-modify-write operations. 



3-2 



iny 



LOCAL BUS INTERFACE 





Table 3-1. Summa 


ry of 80386 Signal Pins 




Signal Name 


Signal Function 


Active 
State 


Input/ 
Output 


Input 
Synch or 
Asynch 
to CLK2 


Output 

High Impedance 

During HLDA? 


CLK2 


Clock 


— 


1 


— 


— 


D0-D31 


Data Bus 


High 


I/O 


S 


Yes 


BE0#-BE3# 


Byte Enables 


Low 





— 


Yes 


A2-A31 


Address Bus 


High 





— 


Yes 


W/R# 


Write-Read Indication 


High 





— 


Yes 


D/C# 


Data-Control Indication 


High 





— 


Yes 


M/IO# 


Memory-l/0 Indication 


High 





— 


Yes 


LOCK# 


Bus Lock Indication 


Low 





— 


Yes 


ADS# 


Address Status 


Low 





— 


Yes 


NA# 


Next Address Request 


Low 


1 


s 


— 


BS16# 


Bus Size 16 


Low 


1 


s 


— 


READY# 


Transfer Acknowledge 


Low 


1 


s 


— 


HOLD 


Bus Hold Request 


High 


1 - 


s 


—,. : 


HLDA 


Bus Hold Acknowledge 


High 





— 


No 


PEREQ 


Coprocessor Request 


High 


1 


A 


— 


BUSY# 


Coprocessor Busy 


Low 


1 


A 


— 


ERROR# 


Coprocessor Error 


Low 


1 


A 


— 


INTR 


Maskable Interrupt Request 


High 


1 


A 


— 


NMI 


Non-Maskable Intrpt Request 


High 


1 


A 


— 


RESET 


Reset 


High 


1 


S 


— 
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Table 3-2. Bus Cycle Definitions 




M/IO# 


D/C# 


W/R# 


Bus Cycle Type 


Locked? 


Low 


Low 


Low 


INTERRUPT ACKNOWLEDGE 


Yes 


Low 


Low 


High 


does not occur 


— 


Low 


High 


Low 


I/O DATA READ 


No 


Low 


High 


High 


I/O DATA WRITE 


No 


High 


Low 


Low 


MEMORY CODE READ 


No 


High 


Low 


High 


HALT: SHUTDOWN: 
Address = 2 Address = 


No 


(BEO# High (BEO# Low 
BE1#High BE1#High 
BE2# Low BE2# High 
BE3#High BE3# High 
A2-A31 Low) A2-A31 Low) 


High 


High 


Low 


MEMORY DATA READ 


Some Cycles 


High 


High 


High 


MEMORY DATA WRITE 


Some Cycles 



3.1.1 Bus States 

The 80386 uses a double-frequency clock input (CLK2) to generate its internal processor 
clock signal (CLK). As shown in Figure 3-1, each CLK cycle is two CLK2 cycles wide. 

Notice that the internal 80386 matches the external 82384 CLK. The 82384 CLK is permit- 
ted to lag CLK2 slightly, but will never lead CLK2, so that it can be used reliably as a phase 
status indicator. All 80386 inputs are sampled at CLK2 rising edges. Many 80386 signals 
are sampled every other CLK2 rising edge; some are sampled on the CLK2 edge when CLK 
is high, while some are sampled on the CLK2 edge when CLK is low. The maximum data 
transfer rate for a bus operation, as determined by the 80386 internal clock, is 32 bits for 
every two CLK cycles, or 32 megabytes per second (CLK2 = 32 MHz, internal CLK = 16 
MHz). 

Each bus cycle is comprised of at least two bus states, Tl and T2. Each bus state in turn 
consists of two CLK2 cycles, which can be thought of as Phase 1 and Phase 2 of the bus 
state. Figure 3-2 shows bus states for some typical read and write cycles. During the first 
bus state (Tl), address and bus status pins go active. During the second bus state (T2), 
external logic and devices respond. If the READY# input of the 80386 is sampled low at 
the end of the second CLK cycle, the bus cycle terminates. If READY# is high when sampled, 
the bus cycle continues for an additional T2 state, called a wait state, and READY# is 
sampled again. Wait states are added until READY# is sampled low. 
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Figure 3-1. CLK2 and CLK Relationship 

When no bus cycles are needed by the 80386 (no bus requests are pending, the 80386 remains 
in the idle bus state (TI). The relationship between Tl, T2, and TI is shown in Figure 3-3. 

3.1.2 Address Pipelining 

In the 80386, the timing address and status outputs can be controlled so the outputs become 
valid before the end of the previous bus cycle. This technique, which allows bus cycles to be 
overlapped, is called address pipeUning. Figure 3-4 compares non-pipelined address cycles to 
pipehned address cycles. 

Address pipelining increases bus throughput without decreasing allowable memory or I/O 
access time, thus allowing high bandwidth with relatively inexpensive components. In addition, 
using pipelining to address slower devices can yield the same throughput as addressing faster 
devices with no pipelining. A 16-MHz 80386 can transfer data at the maximum rate of 32 
megabytes per second while allowing an address access time of three CLK cycles 
(187.5 nanoseconds at CLK = 16 MHz neglecting signal delays); without address pipelin- 
ing, the access time is only two CLK cycles (125 nanoseconds at CLK = 16 MHz). When 
address pipeline is activated following an idle bus cycle, performance is decreased slightly 
because the first bus cycle cannot be pipelined. This condition is explained fully in 
Chapter 4. 

3.1.3 32-Bit Data Bus Transfers and Operand Alignment 

The 80386 can address up to four gigabytes (2^2 bytes, addresses OOOOOOOOH-FFFFFFFFH) 
of physical memory and up to 64 kilobytes (2'^ bytes, addresses OOOOOOOOH-OOOOFFFFH) 
of I/O. The 80386 maintains separate physical memory and I/O spaces. 
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Figure 3-2. 80386 Bus States Timing Example 

The programmer views the address space (memory or I/O) of the 80386 as a sequence of 
bytes. Words consist of two consecutive bytes, and double words consist of four consecutive 
bytes. However, in the system hardware, address space is implemented in four sections. Each 
of the four 8-bit portions of the data bus (D0-D7, D8-D15, D16-D23, and D24-D31) connects 
to a section. When the 80386 reads a doubleword, it accesses one byte from each section. 
The 80386 automatically translates the programmers' view of consecutive bytes into this 
hardware implementation (see Figure 3-5). 

The 80386 memory spaces and I/O space are organized physically as sequences of 32-bit 
doublewords (2^^ 32-bit memory locations and 2^"^ 32-bit I/O ports maximum). Each double- 
word starts at a physical address that is a multiple of four, and has four individually address- 
able bytes at consecutive addresses. 
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Bus States: ^ 

T1 — first clock of a non-pipelined bus cycle (80386 drives new address and asserts ADS#) 

T2 — subsequent clocks of a bus cycle when NA# has not been sampled asserted in the current bus cycle 

Ti — idle state 

The fastest bus cycle consists of two states: TI and T2. 
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Figure 3-3. Bus State Diagram (Does Not Include Address Pipelining) 

Pins A31-A2 correspond to the most significant bits of the physical address; these pins address 
doublewords of memory. The two least significant bits of the physical address are used inter- 
nally to activate the appropriate byte enable output (BE3#-BE0#). Figure 3-6 shows the 
relationship between physical address, doubleword location, data bus pins, and byte enables. 
This relationship holds for a 32-bit bus only; the organization for a 16-bit bus is described 
later in Section 3.1.10. 



Data can be transferred in quantities of 32 bits, 24 bits, 16 bits, or 8 bits for each bus cycle 
of a data transfer. Table 3-3 shows which bytes of a 32-bit doubleword can be transferred 
in a single bus cycle. If a data transfer can be completed in a single cycle, the transfer is 
said to be aligned. For example, a word transfer involving D23-D8 and activating BE1# and 
BE2# is aligned. 



Transfers of words and doublewords that overlap a doubleword boundary of the 80386 are 
called misaligned transfers. These transfers require two bus cycles, which are automatically 
generated by the 80386. For example, a word transfer at (byte) address 0003H requires two 
byte transfers: the first transfer activates doubleword address 0004H and uses D7-D0, and 
the second transfer activates doubleword address OOOOH and uses D31-D24. 
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Figure 3-4. Non-Pipelined Address and Pipelined Address Differences 
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Figure 3-5. Consecutive Bytes in l-lardware Implementation 
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Figure 3-6. Address, Data Bus, and Byte Enables for 32-Bit Bus 
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Table 3-3. Possible Data Transfers on 32-Bit Bus 



Possible Data Transfers to 32-Bit Memory 


Size 


Byte Enables 


32 bits 


3-2-1-0 


24 bits 


3-2-1 
2-1-0 


16 bits 


3-2 
2-1 
1-0 


8 bits 


3 
2 
1 




Figure 3-7 shows the steps required for a misaligned 32-bit transfer. In the first bus cycle, 
the physical address crosses over into the next doubleword location, and BEO# and BE1# are 
active. In the second bus cycle, the address is decremented to the previous doubleword, and 
BE2# and BE3# are active. After the transfer, the data bits are automatically assembled in 
the correct order. 

Table 3-4 shows the sequence of bus cycles for all possible misaligned transfers. Even though 
misaligned transfers are transparent to a program, they are slower than aligned transfers 
and should thus be avoided. 

Because the 80386 operates on only bytes, words, and doublewords, certain combinations of 
BE3#-BE0# are never produced. For example, a bus cycle is never performed with only 
BEO# and BE2# active because such a transfer would be an operation on two noncontiguous 
bytes at the same time. A single 3-byte transfer will never occur, but a 3-byte transfer followed 
or preceded by a 1-byte transfer can occur for some misaligned doubleword transfers. 



3.1.4 Read Cycle 



Read cycles are of two types: pipelined address cycles and non-pipelined address cycles. In 
a non-pipelined address cycle, the address bus and bus status signals become valid during 
the first CLK period of the cycle. In a pipelined address cycle, the address bus and bus status 
signals are output before the beginning of cycle, in the previous bus cycle, to allow longer 
memory access times. Pipelined address cycles are described in Section 3.1.6. 

The timing for two non-pipelined address read cycles (one with and one without a wait state) 
is shown in Figure 3-8. 
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Figure 3-7. Misaligned Transfer 
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Figure 3-8. Non-Pipelined Address Read Cycles 
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Table 3-4. Misaligned Data Transfers on 32-Bit Bus 







First Cycle: 


Second Cycle: 


Transfer 
Type 


Physical 
Address 


Address 
Bus 


Byte 
Enables 


Address 
Bus 


Byte 
Enables 


Word 


4N + 3 


4N + 4 





4N 


3 


Doubleword 


4N + 1 


4N + 4 





4N 


1-3 


Doubleword 


4N + 2 


4N + 4 


0-1 


4N 


2-3 


Doubleword 


4N + 3 


4N -h 4 


0-2 


4N 


3 



NOTE: 4N = Nth doubleword address 

The sequence of signals for the non-pipelined cycle is as follows: 

• The 80386 initiates the cycle by driving ADS# low. The states of the address bus 
(A31-A2), byte enable pins (BE3#-BE0#), and bus status outputs (M/IO#, D/C#, 
W/R#, and LOCK#) at the CLK2 edge when ADS# is sampled low determine the type 
of bus cycle to be performed. For a read cycle, 

— W/R#islow 

— M/IO# is high for a memory read, low for an I/O read 

— For a memory read, D/C# is high if data is to be read, low if an instruction is to be 
read. Immediate data is included in an instruction. 

— LOCK# is low if the bus cycle is a locked cycle. Only a memory data read cycle (in a 
read-modify-write sequence) can be locked. No other bus master should be permitted 
to control the bus between two locked bus cycles. 

The address bus, byte enable pins, and bus status pins (with the exception of ADS#) 
remain active through the end of the read cycle. 

• At the end of T2, READY# is sampled. If READY# is low, the 80386 reads the input 
data on the data bus. 

• If READY# is high, wait states (one CLK cycle) are added until READY# is sampled 
low. READY# is sampled at the end of each wait state. 

• Once READY# is sampled low, the 80386 reads the input data, and the read cycle termi- 
nates. If a new bus cycle is pending, it begins on the next CLK cycle. 



3.1.5 Write Cycle 

Write cycles, like read cycles, are of two types: pipelined address and non-pipelined address. 
Pipelined address cycles are described in Section 3.1.6. 
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Figure 3-9 shows two non-pipelined address write cycles (one with and one without a wait 
state. The sequence of signals for a non-pipelined write cycle is as follows: 

• The 80386 initiates the cycle by driving ADS# low. The states of the address bus 
(A31-A2), byte enable pins (BE3#-BE0#), and bus status outputs (M/IO#, D/C#, 
W/R#, and LOCK#) at the CLK edge when ADS# is sampled low to determine the type 
of bus cycle to be performed. For a write cycle, 

— W/R#ishigh 

— M/IO# is high for a memory write, low for an I/O write 

— D/C#ishigh 

— LOCK# is low if the bus cycle is a locked cycle. Only a memory write cycle (in a read- 
modify-write sequence) is locked. No other bus master should be permitted to control 
the bus between two locked bus cycles. 

The address bus, byte enable pins, and bus status pins (with the exception of ADS#) 
remain active through the end of the write cycle. 

• At the start of Phase 2 in Tl, output data becomes valid on the data bus. This data 
remains vaHd until the start of Phase 2 in Tl of the next bus cycle. 

• At the end of T2, READY# is sampled. If READY# is low, the write cycle terminates. 

• If READY# is not low, wait states are added until READY# is sampled low. READY# 
is sampled at the end of each wait state. 

• Once READY# is sampled low, the write cycle terminates. If a new bus cycle is pending, 
it begins on the next CLK cycle. 



3.1.6 Pipelined Address Cycle 

Address pipelining allows bus cycles to be overlapped, increasing the amount of time avail- 
able for the memory or I/O device to respond. The NA# input of the 80386 controls address 
pipelining. NA# is generated by logic in the system to indicate that the address bus is no 
longer needed (for example, after the address has been latched). If the system is designed so 
that NA# goes active before the end of the cycle, address pipelining may occur. 

NA# is sampled at the rising CLK2 edge of Phase 2 of each CLK cycle. Once NA# is 
sampled active, the address, byte enables, and bus status signals for the next bus cycle are 
output as soon as they are available internally. Once NA# is sampled active, it is not required 
again until the CLK cycle after ADS# goes active. 

Figure 3-10 illustrates the effect of NA#. During the second CLK cycle (T2) of a non- 
pipelined address cycle, NA# is sampled low. The address, byte enables, and bus status 
signals for the next bus cycle are output in the third CLK cycle (the first wait state of the 
current bus cycle). Thereafter, NA# is sampled in the next CLK cycle after ADS# is valid 
(Tl of each bus cycle); if NA# is active, the address, byte enables and bus-status pins for 
the next cycle are output in T2 if another bus cycle is pending. 
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Figure 3-9. Non-Pipelined Address Write Cycles 
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Following any idle bus state (Ti), addresses are non-pipelined. Within non-pipelined bus cycles, NA# is only sampled during wait states. 
Therefore, to begin address pipelining during a group of non-pipelined bus cycles requires a non-pipelined cycle with at least one wait state 
(Cycle 2 above). 
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Figure 3-10. Pipelined Address Cycles 

The first bus cycle after an idle bus state is always non-pipelined. To initiate address pipelin- 
ing, this cycle must be extended by at least one CLK cycle so that the address and status 
can be output before the end of the cycle. Subsequent cycles can be pipelined as long as no 
idle bus cycles occur. 

NA# is sampled at the start of Phase 2 of any CLK cycle in which ADS# is not active, 
specifically, 

• The second CLK cycle of a non-pipelined address cycle 

• The first CLK cycle of a pipelined address cycle 

• Any wait state of a non-pipelined address or pipelined address cycle unless NA# has 
already been sampled active 
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Once NA# is sampled active, it remains active internally throughout the current bus cycle. 
If NA# and READY# are active in the same CLK cycle, the state of NA# is irrelevant, 
because READY# causes the start of a new bus cycle; therefore, the new address and status 
signals are always output regardless of the state of NA#. 

A complete discussion of the considerations for using address pipelining can be found in the 
80386 Data Sheet (Order Number 23 1 630). 

3.1.7 Interrupt Acknowledge Cycle 

An unmasked interrupt causes the 80386 to suspend execution of the current program and 
perform instructions from another program called a service routine. Interrupts are described 
in detail in Section 3.4. 

The 8259A Programmable Interrupt Controller is a system component that coordinates the 
interrupts of several devices (eight interrupts for a single 8259A; up to 64 interrupts with 
eight cascaded 8259As). When a device signals an interrupt request, the 8259A activates 
the INTR input of the 80386. 

Interrupt acknowledge cycles are special bus cycles designed to activate the 8259A INTA 
input that enables the 8259A to output a service-routine vector on the data bus. The 80386 
performs two back-to-back interrupt acknowledge cycles in response to an active INTR input 
(as long as the interrupt flag of the 80386 is enabled). 

Interrupt acknowledge cycles are similar to regular bus cycles in that the 80386 bus outputs 
signals at the start of each bus cycle and an active READY# terminates each bus cycle. The 
cycles are shown in Figure 3-11. 

• ADS# is driven low to start each bus cycle. 

• Control signals M/IO#, D/C#, and W/R# are driven low to signal to interrupt- 
acknowledge bus cycles. These signals must be decoded to generate the INTA input signal 
for the 8259A. The decoding logic is usually included in the bus controller logic for the 
particular design. Bus controller designs are discussed in Chapters 6 and 8. 

• LOCK# is active from the beginning of the first cycle to the end of the second. HOLD 
requests from other bus masters are not recognized until after the second interrupt 
acknowledge cycle. 

• The address driven during the first cycle is 4; during the second cycle, the address is 0. 
BE3#, BE2#, and BE1# are high, BEO# is low, and A31-A3 are low for both cycles; 
A2 is high for the first cycle and low for the second. 

• The 80386 floats D31-D0 for both cycles; however, at the end of the second cycle, the 
service routine vector at the 8259 A outputs is read by the 80386 on pins D7-D0. 

• READY# must go low to terminate each cycle. 

System logic must delay READ Y# to extend the cycle to the minimum pulse-width require- 
ment of the 8259A Programmable Interrupt Controller. In addition, the 80386 inserts at 
least 160 nanoseconds of bus idle time (four Ti states) between the two cycles to match the 
recovery time of the 825 9 A. 
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231630-26 
Interrupt Vector (0-255) is read on D0-D7 at end of second Interrupt Acknowledge bus cycle. 

Because each Interrupt Acknowledge bus cycle is followed by idle bus states, asserting NA# has no practical effect. Choose the approach 
which is simplest for your system hardware design. 
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Figure 3-11. Interrupt Acknowledge Bus Cycles 

3.1.8 Halt/Shutdown Cycle 

The halt condition in the 80386 occurs in response to a HLT instruction. The shutdown 
condition occurs when the 80386 is processing a double fault and encounters a protection 
fault; the 80386 cannot recover and shuts down. Halt or shutdown cycles result from these 
conditions. Externally, a shutdown cycle differs from a halt cycle only in the resulting address 
bus outputs. 

As with other bus cycles, a halt or shutdown cycle is initiated by activating ADS# and the 
bus status pins as follows: 

• M/IO# and W/R# are driven high, and D/C# is driven low to indicate a halt cycle. 
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• All address bus outputs are driven low. For a halt condition, BE2# is active; for a shutdown 
condition, BEO# is active. These signals are used by external devices to respond to the 
halt or shutdown cycle. 

READY# must be asserted to complete the halt or shutdown cycle. The 80386 will remain 
in the halt or shutdown condition until... 

• NMI goes high; 80386 services the interrupt 

• RESET goes high; 80386 is reinitialized 

In the halt condition (but not in the shutdown condition), if maskable interrupts are enabled, 
an active INTR input will cause the 80386 to end the halt cycle to service the interrupt. The 
80386 can service processor extension (PEREQ input) requests and HOLD (HOLD input) 
requests while in the halt or shutdown condition. 

3.1.9 BS16 Cycle 

The 80386 can perform data transfers for both 32-bit and 16-bit data buses. A control input, 
BS16#, allows the bus size to be specified for each bus cycle. This dynamic bus sizing gives 
the 80386 flexibility in using 16-bit components and buses. 

The BS16# input causes the 80386 to perform data transfers for a 16-bit data bus (using 
data bus signals D15-D0) rather than a 32-bit data bus. The 80386 automatically performs 
two or three cycles for data transfers larger than 16 bits and for misaligned (odd-addressed) 
16-bit transfers. 

BS16# must be supplied by external hardware, either through chip select decoding or directly 
from the addressed device. BS16# is sampled at the start of Phase 2 only in CLK cycle as 
long as ADS# is not active. If BS16# and READY# are sampled low in the same CLK cycle, 
the 80386 assumes a 16-bit data bus. 

The BS16# control input affects the performance of a data transfer only for data transfers 
in which 1) BEO# or BE1# is active and 2) BE2# or BE3# is active at the same time. In 
these transfers, the 80386 must perform two bus cycles using only the lower half of the data 
bus. 

If a BS 16 cycle requires an additional bus cycle, the 80386 will retain the current address 
for the second cycle. Address pipelining cannot be used with BS16 cycles because address 
pipeUning requires that the next address be generated on the bus before the end of the current 
bus cycle. Therefore, because both signals are sampled at the same sampling window, BS16# 
must be active before or at the same time as NA# to guarantee 16-bit operation. Once NA# 
is sampled active in a bus cycle and BS16# is not active at that time, BS16# is locked out 
internally. 

If BS16# is asserted during the last clock of the bus cycle and NA# was not asserted previ- 
ously in the bus cycle, then the processor performs a 16-bit bus cycle. This is true, even if 
NA# is asserted during the last clock of the bus cycle. Figure 3-12 illustrates this logic. 
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Figure 3-12. Internal NA# and BS16# Logic 

Figure 3-13 compares the signals for 32-bit and 16-bit bus cycles. 

3.1.10 1 6-Bit Byte Enables and Operand Alignment 

For a 16-bit data bus, the 80386 views memory and I/O as sequences of 16-bit words. For 
this configuration, the Bus High Enable (BHE#), AO or Bus Low Enable (BLE#), and Al 
signals are needed. BHE# and BLE# are byte enables that correspond to two banks of memory 
in the same way that BE3#-BE0# correspond to four banks. Al is added to A31-A2 to 
generate the addresses of 2-byte locations instead of 4-byte locations. Figure 3-14 compares 
the addressing configurations of 32-bit and 16-bit data buses. 

The BHE#, BLE#, and Al signals can be generated from BE3#, BE2#, BE1#, and BEO# 
using just four external logic gates. Table 3-5 shows the truth table for this conversion. Note 
that certain combinations of BE3#-BE0# are never generated. 

When BS16# is sampled active, the states of BE3#-BE0# determine how the 80386 responds: 

• BS16# has no effect if activated for a bus cycle in which BE3# and BE2# are inactive. 

• If BEO# and BE1# are both inactive during a BS16 cycle, and either BE2# or BE3# is 
active, 

— For a write cycle, data on D31-D16 is duplicated on D15-D0, regardless of the state 
of BS16#. (This duplication occurs because BS16# is sampled late in the cycle but 
data must be available early). 

— For a read cycle, data that would normally be read on D31-D24 is read on D15-D8, 
and data that would normally be read on D23-D16 is read on D7-D0. 

• If BEO# or BE1# is active, and BE2# or BE3# is active, two bus cycles are required. The 
two cycles are identical except BEO# and BE1# are inactive in the second cycle and 

— For a write cycle, the data that was on D31-D16 in the first cycle is copied onto 
D15-D0. 

— For a read cycle, data that would normally be read on D31-D24 is read on D15-D8, 
and data that would normally be read on D23-D16 is read on D7-D0. 
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Figure 3-13. 32-Bit and 16-Bit Bus Cycle Timing 
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Figure 3-14. 32-Bit and 16-Blt Data Addressing 

Table 3-6 shows which combinations of BE3#-BE0# require two bus cycles and the states of 
BE3#-BE0# for each cycle. 

In some cases, 1 6-bit cycles may be performed without using BS 1 6#. Address pipelining may 
be used as follows for these cycles. 

• BS16# is not needed for cycles that use only D15-D0. 

• BS16# is not needed for a word-aligned 16-bit write. For write cycles, all 32 bits of the 
data bus are driven regardless of bus size. 



3.2 BUS TIMING 

This section describes timing requirements for read cycles, write cycles, and the READY# 
signal. 

All 80386 signals have setup and hold time requirements relative to CLK2. The timings of 
certain signals relative to one another depends on whether address pipelining is used. These 
facts must be considered when determining external logic needed to facilitate bus cycles. 
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Table 3-5. Generation of BHE#, BLE#, 


and A1 from Byte Enables 


80386 Signals 


16-Bit Bus Signals 










Comments 


BE3# 


BE2# 


BE1# 


BEO# 


A1 


BHE# 


BLE# (AO) 


H* 


H* 


H* 


H* 


X 


X 


X 


X— no active bytes 


H 


H 


H 


L 


L 


H 


L 




H 


H 


L 


H 


L 


L 


H 




H 


H 


L 


L 


L 


L 


L 




H 


L 


H 


H 


H 


H 


L 




H* 


L* 


H* 


L* 


X 


X 


X 


X— not contiguous bytes 


H 


L 


L 


H 


L 


L 


H 




H 


L 


L 


L 


L 


L 


L 




L 


H 


H 


H 


H 


L 


H 




L* 


H* 


H* 


L* 


X 


X 


X 


X— not contiguous bytes 


L* 


H* 


L* 


H* 


X 


X 


X 


X— not contiguous bytes 


L* 


H* 


L* 


L* 


X 


X 


X 


X — not contiguous bytes 


L 


L 


H 


H 


H 


L 


L 




L* 


L* 


H* 


L* 


X 


X 


X 


X — not contiguous bytes 


L 


L 


L 


H 


L 


L 


H 




L 


L 


L 


L 


L 


L 


L 




BLE# asserted when D0-D7 of 16-bit bus is active. 






BHE# asserted when D8-D15 of 16-bit bus is active. 






A1 low for all even words; A1 high for all odd words. 






Key: 






X = don't care 






H = high voltage level 






L = low voltage level 






* = a non-occurring pattern of Byte Enables; either none 


are asserted, or 


the pattern has Byte Enables 


asserted for non-contiguous bytes 







Table 3-6. Byte Enables during BS16 Cycles 



First Cycle: 


Second Cycle: 


BE3# 


BE2# 


BE1# 


BEO# 


BE3# 


BE2# 


BE1# 


BEO# 


High 
High 
High 
High 
High 
High 
Low 
Low 
Low 
Low 


High 
High 
High 
Low 
Low 
Low 
High 
Low 
Low 
Low 


High 
Low 
Low 
High 
Low 
Low 
High 
High 
Low 
Low 


Low 
High 
Low 
High 
High 
Low 
High 
High 
High 
Low 


None 

None 

None 

None 

High 

High 

None 

None 

Low 

Low 


Low 
Low 

Low 
Low 


High 
High 

High 
High 


High 
High 

High 
High 
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The analyses that follow are based on the assumption that a 16-MHz 80386 is used. If the 
processor is operated at a different frequency, the timings will change accordingly. Example 
worst-case signal parameter values from the 80386 Data Sheet (Order Number 231630) are 
used; consult the most recent data sheet to confirm these values . Also note that delay times 
and setup times must be factored into the timing of system response and interaction with 
the 80386 to ensure comfortable margins for all critical timings. 



3.2.1 Read Cycle Timing 

For read cycles, the minimum amount of time from the output of valid addresses to the 
reading of the data bus sets an upper limit on memory access times (including address 
decoding time). In a non-pipelined address cycle, this time is 

Four CLK2 cycles 125 nanoseconds 

— A31-A2 output delay (maximum) —40 nanoseconds 

— D31-D0 input setup (minimum) — 10 nanoseconds 



75 nanoseconds 

With address pipelining and no wait states, the address is valid one CLK cycle earlier: 

Non-pipelined value 75 nanoseconds 

+ One CLK cycle (2 CLK2 cycles) +62.5 nanoseconds 



137.5 nanoseconds 
For both cases above, each wait state in the bus cycle adds 62.5 nanoseconds. 

3.2.2 Write Cycle Timing 

For write cycles, the elapsed time from the output of valid address to the end of the cycle 
determines how quickly the external logic must decode and latch the address. In a non- 
pipelined address cycle, this time is 

Four CLK2 cycles 125 nanoseconds 

— A31-A2 output delay (maximum) —40 nanoseconds 



85 nanoseconds 



(With address pipelining) (+ 62.5 nanoseconds) 

(With N wait states) (+ N*62.5 nanoseconds) 
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The minimum amount of time from the output of valid write data by the access device to 
the end of the write cycle is the least amount of time external logic has to read the data. 
This setup time is 

Three CLK2 cycles 93.75 nanoseconds 

— D31 -DO output delay (maximum) —50 nanoseconds 



43.75 nanoseconds 

(With N wait states) (+ N*62.5 nanoseconds) 

Data outputs are valid beyond the end of the bus cycle. This data hold time is at least 

One CLK2 cycle 31.25 nanoseconds 

+ D31 -DO hold time (minimum) + 1 nanoseconds 



32.25 nanoseconds 

(Wait states do not affect this parameter) 

Wait states add the same amounts of data-to-end-of-cycle time as they do for read cycles. 
(See Section 3.2.1.) 



3.2.3 READY# Signal Timing 

The amount of time from the output of valid address signals to the assertion of READY# to 
end a bus cycle determines how quickly external logic must generate the READY# signal. 
READY# must meet the 80386 setup time. In a nonpipelined address cycle, READY# signal 
timing is as follows: 

Four CLK2 cycles 125 nanoseconds 

— A31-A2 output delay (maximum) —40 nanoseconds 

— READY# setup (minimum) —20 nanoseconds 



65 nanoseconds 



(With address pipelining) (-f 62.5 nanoseconds) 

(With N wait states) (+ N*62.5 nanoseconds) 

Again, pipelining and wait states increase this amount of time. 

Because the efficiency of a cache depends upon quick turnaround of cache hits (i.e., when 
requested data is found in the cache) the timing of the READY# signal is critical; therefore, 
READY# is typically generated combinationally from the cache hit comparator. If the 
READY# signal is returned too slowly, the speed advantage of the cache is lost. 
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3.3 CLOCK GENERATION 



3.3.1 82384 Clock Generator 

The 82384 Clock Generator is a multifunction component of the 80386 system that provides 
clocking for synchronous operation of the 80386 and its support components as follows: 

• Both CLK2 (a double-frequency clock for the 80386 and some support devices) and CLK 
(a system clock for some 80386 support devices) are generated. The phase of the 82384 
CLK matches that of the CLK signal generated internally by the 80386. 

• The RESET signal for the 80386 and other system components is generated. The RES# 
input of the 82384 accepts an asynchronous input from a simple RC circuit or similar 
source, synchronizes the signal with CLK, and outputs the active-high RESET signal to 
the 80386 and other system components. The timing and function of the RESET signal 
with respect to the 80386 is discussed later in this chapter. 

• The 82384 uses the ADS# output of the 80386 (which guarantees setup and hold time to 
CLK2) to generate an ADSO# signal, which is functionally equivalent to ADS# but 
guarantees setup and hold times with respect to CLK. Devices that are clocked with the 
CLK output of the 82384 can use ADSO#. 

Figure 3-15 shows a typical circuit to connect the 82384 to the 80386. 

Either an external frequency source or a third overtone crystal can be used to drive the 
82384. The F/C# input indicates the signal source; if F/C# is pulled high, the 82384 recog- 
nizes the signal on its External Frequency Input (EFI) pin as its frequency source. If F/C# 
is tied low, the crystal connected to the XI and X2 pins of the 82384 is its frequency source. 
In either case, the source frequency must equal the desired CLK2 frequency. For example, 
a 32 MHz crystal yields a 32 MHz CLK2 signal and a 16 MHz 80386 internal clock rate. 



3.3.2 Clock Timing 

The CLK2 and CLK outputs of the 82384 are both MOS-level outputs with output high 
voltage levels of Vcc~0.6V and adequate drive for TTL inputs. CLK2 is twice the frequency 
of CLK. 

The internal CLK signal of the 80386 is matched to the CLK output of the 82384 by the 
falling edge of the RESET signal. This operation is described with the RESET function in 
Section 3.8. 

The skew between the 82384 CLK2 and CLK signals is maintained at 0-16 nanoseconds 
(regardless of clock frequency). For closely timed interfaces, peripheral devices must be 
timed by CLK2. Devices that cannot be operated at the double-clock frequency must use 
the CLK output of the 82384. The 80386 interface to these devices must allow for the CLK2- 
to-CLKskew. 
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Figure 3-15. Ccnnecting 82384 to 8G386 

The phase of the CLK output of the 82384 is useful for determining the beginning of a bus 
cycle. Because each CLK2 cycle is 31.25 nanoseconds (at CLK2 = 32 MHz), and bus 
status signal delays may be as much as 35 nanoseconds, it is impossible to tell from these 
status signals alone which CLK2 cycle begins the bus cycle, and therefore when to expect 
valid address signals. The phase of CLK can be used to make this determination. ADS# 
should be sampled on rising CLK2 transitions when CLK is high, i.e., at the end of phase 2 
(see Figure 3-16). 



3.4 INTERRUPTS 

Both hardware-generated and software-generated interrupts can alter the programmed 
execution of the 80386. A hardware-generated interrupt occurs in response to an active input 
on one of two 80386 interrupt request inputs (NMI or INTR). A software-generated inter- 
rupt occurs in response to an INT instruction or an exception (a software condition that 
requires servicing). For complete information on software-generated interrupts, see the 80386 
Programmer's Reference Manual, 
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Figure 3-16. Using CLK to Determine Bus Cycle Start 

In response to an interrupt request, the 80386 processes the interrupt (saves the processor 
state on the stack, plus task information if a task switch is required) and services the inter- 
rupt (transfers program execution to one of 256 possible interrupt service routines). Entry- 
point descriptors to service routines or interrupt tasks are stored in a table (Interrupt 
Descriptor Table or IDT) in memory. To access a particular service routine, the 80386 must 
obtain a vector, or index, to the table location that contains the corresponding descriptor. 
The source of this vector depends on the type of interrupt; if the interrupt is maskable (INTR 
input active), the vector is supplied by the 8259A Interrupt Controller. If the interrupt is 
nonmaskable (NMI input active), location 2 in the IDT is used automatically. 

The NMI request and the INTR request differ in that the 80386 can be programmed to 
ignore INTR requests (by clearing the interrupt flag of the 80386). An NMI request always 
provokes a response from the 80386 unless the 80386 is already servicing a previous NMI 
request. In addition, an INTR request causes the 80386 to perform two interrupt- 
acknowledge bus cycles to fetch the service-routine vector. These bus cycles are not required 
for an NMI request, because the vector location for an NMI request is fixed. 

Under the following two conditions a service routine will not be interrupted by an incoming 
interrupt: 

• The incoming interrupt is an INTR request, and the 80386 is programmed to ignore 
maskable interrupts. (The 80386 is automatically programmed to ignore maskable inter- 
rupts when it receives any interrupt request. This condition may be changed by the inter- 
rupt service routine.) In this case, the INTR request will be serviced only if it is still 
active when maskable interrupts are reenabled. 
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• The incoming interrupt is an NMI, and the 80386 is servicing a previous NMI. In this 
case, the NMI is saved automatically to be processed after the IRET instruction in the 
NMI service routine has been executed. Only one NMI can be saved; any others that 
occur while the 80386 is servicing a previous NMI will not be recognized. 

If neither of the above conditions is true, and an interrupt occurs while the 80386 is servicing 
a previous interrupt, the new interrupt is processed and serviced immediately. The 80386 
then continues with the previous service routine. The last interrupt processed is the first one 
serviced. 

If an NMI request and an INTR request arrive at the 80386 simultaneously, the NMI 
request is processed first. Multiple hardware interrupts arriving at the 8259A are processed 
according to their priority and are sent to the 80386 INTR input one at a time. 

3.4.1 Non-Maskable Interrupt (NMI) 

The NMI input of the 80386 generally signals a catastrophic event, such as an imminent 
power loss, a memory error, or a bus parity error. This input is edge-triggered (on a low-to- 
high transition) and asynchronous. A valid signal is low for eight CLK2 periods before the 
transition and high eight CLK2 periods after the transition. The NMI signal can be 
asynchronous to CLK2. 

An NMI request automatically causes the 80386 to execute the service routine correspond- 
ing to location 2 in the IDT. The 80386 will not service subsequent NMI requests until the 
current request has been serviced. The 80386 disables INTR requests (although these can 
be reenabled in the service routine) in Real Mode. In Protected Mode, the disabling of 
INTR requests depends on the gate in IDT location 2. 

3.4.2 Maskable Interrupt (INTR) 

The INTR input of the 80386 allows external devices to interrupt 80386 program execution. 
To ensure recognition by the 80386, the INTR input must be held high until the 80386 
acknowledges the interrupt by performing the interrupt acknowledge sequence. The INTR 
input is sampled at the beginning of every instruction; it must be high at least eight CLK2 
periods prior to the instruction to guarantee recognition as a valid interrupt. This require- 
ment reduces the possibility of false inputs from voltage glitches. In addition, maskable 
interrupts must enabled in software for interrupt recognition. The INTR input may be 
asynchronous to CLK2. 

The INTR signal is usually supplied by the 8259A Programmable Interrupt Controller, which 
in turn is connected to devices that require interrupt servicing. The 8259A, which is controlled 
by commands from the 80386 (the 8259A appears as a set of I/O ports), accepts interrupt 
requests from devices connected to the 8259A, determines the priority for transmitting the 
requests to the 80386, activates the INTR input, and supplies the appropriate service routine 
vector when requested. 

An INTR request causes the 80386 to execute two back-to-back interrupt acknowledge bus 
cycles, as described earlier in Section 3.1.4. 
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3.4.3 interrupt Latency 

The time that elapses before an interrupt request is serviced (interrupt latency) varies 
according to several factors. This delay must be taken into account by the interrupt source. 
Any of the following factors can affect interrupt latency: 

If interrupts are masked, an INTR request will not be recognized until interrupts are 
reenabled. 

If an NMI is currently being serviced, an incoming NMI request will not be recognized 
until the 80386 encounters the IRET instruction. 

If the 80386 is currently executing an instruction, the instruction must be completed. An 
interrupt request is recognized only on an instruction boundary. (However, Repeat String 
instructions can be interrupted after each iteration.) 

Saving the Flags register and CS:EIP registers (which contain the return address) requires 
time. 

If interrupt servicing requires a task switch, time must be allowed for saving and restoring 
registers. 

If the interrupt service routine saves registers that are not automatically saved by the 
80386, these instructions also delay the beginning of interrupt servicing. 

The longest latency occurs when the interrupt request arrives while the 80386 is executing 
a long instruction such as multiplication, division, or a task-switch in the Protected mode. 

If the instruction loads the Stack Segment register, an interrupt is not processed until after 
the following instruction, which should be an ESP load. This allows the entire stack pointer 
to be loaded without interruption. 

If an instruction sets the interrupt flag (thereby enabling interrupts), an interrupt is not 
processed until after the next instruction. 



3.5 BUS LOCK 

In a system in which more than one device may control the local bus, locked cycles must be 
used when it is critical that two or more bus cycles follow one another immediately. Other- 
wise, the cycles can be separated by a cycle from another bus master. 

Any bus cycles that must be performed back-to-back without any intervening bus cycles by 
other bus masters should be locked. The use of a semaphore is one example of this precept. 
The value of a semaphore indicates a condition, such as the availability of a device. If the 
80386 reads a semaphore to determine that a device is available, then writes a new value to 
the semaphore to indicate that it intends to take control of the device, the read cycle and 
write cycle should be locked to prevent another bus master from reading from or writing to 
the semaphore in between the two cycles. The erroneous condition that could result from 
unlocked cycles is illustrated in Figure 3-17. 
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Figure 3-17. Error Condition Caused by Unlocked Cycles 

The LOCK# output of the 80386 signals the other bus masters that they may not gain 
control of the bus. In addition, an 80386 with LOCK# asserted will not recognize a HOLD 
request from another bus master. 



3.5.1 Locked Cycle Activators 

The LOCK# signal is activated explicitly by the LOCK prefix on certain instructions. LOCK# 
is also asserted automatically for an XCHG instruction, a descriptor update, interrupt 
acknowledge cycles, and a page table update. 
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3.5.2 Locked Cycle Timing 

LOCK# is activated on the CLK2 edge that begins the first locked bus cycle. LOCK# is 
deactivated when READY# is sampled low at the end of the last bus cycle to be locked. 

LOCK# is activated and deactivated on these CLK2 edges whether or not address pipelining 
is used. If address pipelining is used, LOCK# will remain active until after the address bus 
and bus cycle status signals have been asserted for the pipelined cycle. Consequently, the 
LOCK# signal can extend into the next memory access cycle that does not need to be locked. 
(See Figure 3-18). The result is that the use of the bus by another bus master is delayed by 
one bus cycle. 



3.5.3 LOCK# Signal Duration 

The maximum duration of the LOCK# signal affects the maximum HOLD request latency 
because HOLD is not recognized until LOCK# goes inactive. The duration of LOCK# 
depends on the instruction being executed and the number of wait states per cycle. 
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Figure 3-18. L0CK# Signal during Address Pipelining 
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The longest duration of LOCK# in real mode is two bus cycles plus approximately two 
clocks. This occurs during the XCHG instruction and in LOCKed read-modify-write opera- 
tions. The longest duration of LOCK# in protected mode is five bus cycles plus approxi- 
mately fifteen clocks. This occurs when an interrupt (hardware or software interrupt) occurs 
and the 80386 performs a LOCKed read of the gate in the IDT (8 bytes), a read of the 
target descriptor (8 bytes), and a write of the accessed bit in the target descriptor. 



3.6 HOLD/HLDA (Hold Acknowledge) 

The 80386 provides on-chip arbitration logic that supports a protocol for transferring control 
of the local bus to other bus masters. This protocol is implemented through the HOLD input 
and HLDA output. 



3.6.1 HOLD/HLDA Timing 

To gain control of the local bus, the requesting bus master drives the 80386 HOLD input 
active. This signal must be synchronous to the CLK2 input of the 80386. The 80386 responds 
by completing its current bus cycle (plus a second locked cycle or a second cycle required 
by BS16#). Then the 80386 sets all outputs but HLDA to the three-state OFF condition to 
effectively remove itself from the bus and drives HLDA active to signal the requesting bus 
master that it may take control of the bus. 

The requesting bus master must maintain HOLD active until it no longer needs the bus. 
When HOLD goes low, the 80386 drives HLDA low and begins a bus cycle (if one 
is pending). 

For valid system operation, the requesting bus master must not take control of the bus before 
it receives the HLDA signal and must remove itself from the bus before de-asserting the 
HOLD signal. Setup and hold times relative to CLK2 for both rising and falling transitions 
of the HOLD signal must be met. 

When the 80386 receives an active j^OLD input, it completes the current bus cycle before 
relinquishing control of the bus. Figure 3-19 shows the state diagram for the bus including 
the HOLD state. 

During the HOLD state, the 80386 can continue executing instructions in its Prefetch Queue. 
Program execution is delayed if a read cycle is needed while the 80386 is in the HOLD 
state. The 80386 can queue one write cycle internally, pending the return of bus access; if 
more than one write cycle is needed, program execution is delayed until HOLD is released 
and the 80386 regains control of the bus. 

HOLD has priority over most bus cycles, but HOLD is not recognized between two interrupt 
acknowledge cycles, between two repeated cycles of a BS16 cycle, or during locked cycles. 
For the 80386, HOLD is recognized between two cycles required for misaligned data trans- 
fers; for the 8086 and 80286 HOLD it is not recognized. This difference should be consid- 
ered if critical misaligned data transfers are not locked. 
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Figure 3-19. Bus State Diagram with HOLD State 

HOLD is not recognized while RESET is active, but is recognized during the time between 
the high-to-low transition of RESET and the first instruction fetch. 

All inputs are ignored while the 80386 is in the HOLD state, except for the following: 

• HOLD is monitored to determine when the 80386 may regain control of the bus. 

• RESET takes precedence over the HOLD state. An active RESEAT input will reinitialize 
the 80386. 

• One NMI request is recognized and latched. It is serviced after HOLD is released. 
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3.6.2 HOLD Signal Latency 

Because other bus masters such as DMA controllers are typically used in time-critical appli- 
cations, the amount of time the bus master must wait (latency) for bus access can be a 
critical design consideration. 

The minimum possible latency occurs when the 80386 receives the HOLD input during an 
idle cycle. HLDA is asserted on the CLK2 rising edge following the HOLD active input 
(synchronous to CLK2). The latency is at least 

One CLK2 period 31.25 nanoseconds 

+ HOLD setup time (minimum) 25 nanoseconds 

+ HLDA output delay (minimum) 4 nanoseconds 



60.25 nanoseconds 



Because a bus cycle must be terminated before HLDA can go active, the maximum possible 
latency occurs when a bus-cycle instruction is being executed. Wait states increase latency, 
and HOLD is not recognized between certain types of bus cycles. 

3.6.3 HOLD State Pin Conditions 

LOCK#, M/IO#, D/C#, W/R#, ADS#, A31-A2, BE3#-BE0#, and D31-D0 enter the three- 
state OFF condition in the HOLD state. Note that external pullup resistors may be required 
on ADS#, LOCK# and other signals to guarantee that they remain inactive during transi- 
tions between bus masters. 



3.7 RESET 

RESET starts or restarts the 80386. When the 80386 detects a low-to-high transition on 
RESET, it terminates all activities. When RESET goes low again, the 80386 is initialized 
to a known internal state and begins fetching instructions from the reset address. 

3.7.1 RESETTimIng 

The 82384 Clock Generator generates the RESET signal to initialize the 80386 and other 
system components. The 82384 has a Schmitt-trigger RES# input signal used to generate 
the RESET signal from an active-low pulse. The hysteresis on the RES# input prevents the 
RESET output from entering an indeterminate state, so a simple RC circuit can be used to 
generate the RES# input on power-up. Figure 3-20 shows an RC circuit that satisfies timing 
requirements for the RES# input. 

The RESET input of the 80386 must remain high for at least 15 CLK2 periods to ensure 
proper initialization (at least 80 CLK2 periods if self-test is to be performed). The CLK 
output of the 82384 is initialized with the rising edge of RESET. When RESET goes low, 
the 80386 adjusts the falling edge of its internal clock (CLK) to coincide with the start of 
the first CLK2 cycle after the high-to-low transition of RESET. The 82384 times 
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Figure 3-20. Typical RC RESET Timing Circuit 

high-to-low edge of RESET (synchronous to CLK2) so that the phase of the internal CLK 
of the 80386 matches the phase of the CLK output of the 82384. This relationship is shown 
in Figure 3-21. 

On the high-to-low transition of RESET, the BUSY# pin is sampled. If BUSY# is low, the 
80386 will perform a self-test lasting approximately 2^° + 60 CLK2 cycles before it begins 
executing instructions. The 80386 continues with initialization after the test, regardless of 
the test results. 

The 80386 fetches its first instruction from linear address OFFFFFFFOH, sometime between 
350 and 450 CLK2 cycles after the high-to-low transition of RESET (or, if self-test is 
performed, after completion of self-test). Because paging is disabled, linear address 
OFFFFFFFOH is the same as physical address OFFFFFFFOH. This location normally contains 
a JMP instruction to the beginning of the bootstrap program. 



3.7.2 80386 Internal States 



RESET should be kept high for at least one millisecond after V^c and CLK2 have reached 
their DC and AC specifications. 

The 80386 samples its ERROR# input during initialization to determine the type of proces- 
sor extension present in the system. This sampling occurs at some time at least 20 CLK2 
periods after the high-to-low transition of RESET and before the first instruction fetch. If 
the ERROR# input is low, the 80386 assumes that an 80387 numeric coprocessor is being 
used, and the programmer must issue a command (FINIT) to reset the ERROR# input after 
initialization. If ERROR# is high, an 80287 or no processor extension is assumed. In this 
case, a software test must be run to determine whether an 80287 is actually present and to 
set the corresponding flag in the 80386. This test is described in Chapter 5. 
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3.7.3 80386 External States 

RESET causes the 80386 output pins to enter the states shown in Table 3-7. Data bus pins 
enter the three-state condition. 

Prior to its first instruction fetch, the 80386 makes no internal requests to the bus, and, 
therefore, will relinquish bus control if it receives a HOLD request (see Section 3.7 for a 
complete description of HOLD cycles). 

Interrupt requests (INTR and NMI) are not recognized before the first instruction fetch. 



Table 3-7. Output Pin States during RESET 




Pin Name 


Pin State 


LOCK#, D/C#, ADS#, A31-A2 




High 


W/R#, M/IO#, HLDA, BE3#-BE0# 




Low 


D31-D0 




Three-State 
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CHAPTER 4 
PERFORMANCE CONSIDERATIONS 



System performance measures how fast a microprocessing system performs a given task or 
set of instructions. Through increased processing speed and data throughput, an 80386 
operating at the heart of a system can improve overall performance immensely. The design 
of supporting logic and devices for efficient interaction with the 80386 is also important in 
optimizing system performance. 

This chapter describes considerations for achieving high performance in 80386-based systems. 
A variety of examples illustrate the potential performance levels for a number of 
applications. 

4.1 WAIT STATES AND PIPELINING 

Because a system may include devices whose response is slow relative to the 80386 bus cycle, 
the overall system performance is often less than the potential performance of the 80386. 
Two techniques for accommodating slow devices are wait states and address pipelining. The 
designer must consider how to use one or both of these techniques to minimize the impact 
of device performance on system performance. 

The impact of memory device speed on performance is generally much greater than that of 
I/O device speed because most programs require more memory accesses than I/O accesses. 
Therefore, the following discussion focuses on memory performance. 

Wait states are extra CLK cycles added to the 80386 bus cycle. External logic generates 
wait states by delaying the READY# input to the 80386. For an 80386 operating at 16 
MHz, one wait state adds 62.5 nanoseconds to the time available for the memory to respond. 
Each wait state increases the bus cycle time by 50 percent of the zero wait-state cycle time; 
however, overall system performance does not vary in direct proportion to the bus cycle 
increase. The second column of Table 4-1 shows the performance impact (based on an 
example simulation) for memory accesses requiring different numbers of wait states; one 
wait state results in an overall performance decrease of 19 percent. 

Table 4-1. 80386 Performance with Wait States and Pipelining 



Wait States 


Wait States 


Performance Relative 


Bus 
Utilization 


When Address 


When Address 


to Non-Pipelined 


Is Pipelined 


is Not Pipelined 


Wait-State 








1.00 


73% 





1 


0.91 


79% 


1 


1 


0.81 


86% 


1 


2 


0.76 


89% 


2 


2 


0.66 


91% 


2 


3 


0.63 


92% 


3 


3 


0.57 


93% 
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Unlike a wait state, address pipelining increases the time that a memory has to respond by 
one CLK cycle without lengthening the bus cycle. This extra CLK cycle eliminates the output 
delay of the 80386 address and status outputs. Address pipelining overlaps the address and 
status outputs of the next bus cycle with the end of the current bus cycle, lengthening the 
address access time by one or more CLK cycles from the point of view of the accessed 
memory device. An access that requires two wait states without address pipelining would 
require one wait state with address pipelining. The third column of Table 4-1 shows 
performance with pipelining for different wait-state requirements. 

Address pipelining is advantageous for most bus cycles, but if the next address is not avail- 
able before the current cycle ends,the 80386 cannot pipeline the next address, and the bus 
timing is identical to a non-pipelined bus cycle. Also, the first bus cycle after an idle bus 
must always be non-pipehned because there is no previous cycle in which to output the address 
early. If the next cycle is to be pipelined, the first cycle must be lengthened by at least one 
wait state so that the address can be output before the end of the cycle. 

With the 80386, address pipeUning is optional so that bus cycle timing can be closely tailored 
to the access time of the memory device; pipelining can be activated once the address is 
latched externally or not activated if the address is not latched. 

The 80386 NA# input controls address pipelining. When the system no longer requires the 
80386 to drive the address of the current bus cycle (in most systems, when the address has 
been latched), the system can activate the 80386 NA# input. The 80386 outputs the address 
and status signals for the next bus cycle on the next CLK cycle. 

The system must activate the NA# signal without knowing which device the next bus cycle 
will access. In an optimal 80386 system, address pipelining should be used even for fast 
memory that does not require pipelining, because if a fast memory access is followed by a 
pipelined cycle to slower memory, one wait state is saved. If a fast memory access is followed 
by another fast memory access, the extra time is not used, and no processor time is lost. 
Therefore, all devices in a system must be able to accept both pipelined and non-pipelined 
cycles. 

Consider a system in which a non-pipelined memory access requires one wait state and a 
non-pipelined I/O access requires four wait states. The bus control logic reads chip select 
signals from the address decoder to determine whether one or four wait states are required 
for the bus cycle. The bus control logic also determines whether the address has been 
pipelined, because a pipelined cycle requires one less wait state. The system includes logic 
for generating a Bus Idle signal that indicates whether the bus cycle has ended. The bus 
control logic can therefore detect that the address has been pipelined if the Address Status 
(ADS#) signal goes active while the Bus Idle signal is inactive. 

Address pipelining is less effective for I/O devices requiring several wait states. The larger 
the number of wait states required, the less significant the elimination of one wait state 
through pipelining becomes. This fact coupled with the relative infrequency of I/O accesses 
means that address pipelining for I/O devices usually makes little difference to system 
performance. 
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A third and less common approach to accommodating memory speed is reducing the 80386 
operating frequency. Because a slower clock frequency increases the bus cycle time, fewer 
wait states may be required for particular memory devices. At the same time, however, 
system performance depends directly on the 80386 clock frequency; execution time increases 
in direct proportion to the increase in clock period (reduction in clock frequency). A 
12.5-MHz 80386 requires almost 33 percent more time to execute a program than a 
16-MHz 80386 operating with the same number of wait states. 

The design and application determine whether frequency reduction makes sense. In some 
instances, a slight reduction in clock frequency reduces the wait-state requirement and 
increases system performance. Table 4-2 shows that a 12.5-MHz 80386 operating with zero 
wait states yields better performance than a 16-MHz 80386 operating with two wait states. 

Table 4-2. Wait States versus Operating Frequency 



Number of 
Wait States 


16 MHz Without 
Pipelining 


16IVIHzWith 
Pipelining 


12.5 MHz Without 
Pipelining 


12.5 MHz With 
Pipelining 





1.00 


0.91 


0.78 


0.71 


1 


0.81 


0.76 


0.64 


0.59 


2 


0.66 


0.63 


0.52 


0.49 


3 


0.57 


— 


0.45 


— 
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CHAPTER 5 
COPROCESSOR HARDWARE INTERFACE 



A numeric coprocessor enhances the performance of an 80386 system by performing numeric 
instructions in parallel with the 80386. The 80386 automatically passes on these instructions 
to the coprocessor as it encounters them. 

Intel offers two numeric coprocessors: 

• The 80287 performs 16-bit data transfers. With the proper interface, the 80386 supports 
the 80287. 

• The 80387 performs 32-bit data transfers and interfaces directly with the 80386. The 
80387 supports the instruction set of both the 80287 and the 8087, offering additional 
enhancements that include full compatibility with the IEEE Floating-Point Standard, draft 
10. The performance of a 16-MHz 80387 is about eight times faster than that of a 
5-MHz 80287. 

Either an 80287 or an 80387 numeric coprocessor can be included in an 80386 system. The 

80386 samples its ERROR# input during initialization to determine which coprocessor is 
present. As mentioned above, the 80287 and 80387 require different interfaces and therefore 
slightly different protocols. The 80287 data bus is 16 bits wide, whereas the 80387 data bus 
is 32 bits wide. 

Data transfers to and from a coprocessor are accomplished through I/O addresses 
800000F8H and 800000FCH; these addresses are automatically generated by the 80386 for 
coprocessor instructions and allow simple chip-select generation using A31 (high) and 
M/IO# (low). Because A31 is high for coprocessor cycles, the coprocessor addresses lie 
outside the range of the programmed I/O address space and are easy to distinguish from 
programmed I/O addresses. Coprocessor usage is independent of the I/O privilege level of 
the 80386. 

The 80386 has three input signals for controlling data transfer to and from an 80287 or 

80387 coprocessor: BUSY#, Coprocessor Request (PEREQ), and ERROR#. These signals, 
which are level-sensitive and may be asynchronous to the CLK2 input of the 80386, are 
described as follows: 

• BUSY# indicates that the coprocessor is executing an instruction and therefore cannot 
accept a new one. When the 80386 encounters any coprocessor instruction except FNINIT 
and FNCLEX, the BUSY# input must be inactive (high) before the coprocessor accepts 
the instruction. A new instruction therefore cannot overrun the execution of the current 
coprocessor instruction. (Certain 80387 instructions can be transferred when BUSY# is 
active (low). These instructions are queued and do not interfere with the current 
instruction.) 

• PEREQ indicates that the coprocessor needs to transfer data to or from memory. Because 
the coprocessor is never a bus master, all input and output data transfers are performed 
by the 80386. PEREQ always goes inactive before BUSY# goes inactive. 
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ERROR# is asserted after a coprocessor math instruction results in an error that is not 
masked by the coprocessor's control register. The data sheets for the 80287 and 80387 
describe these errors and explain how to mask them under program control. If an error 
occurs, ERROR# goes active before BUSY# goes inactive, so that the 80386 can take 
care of the error before performing another data transfer. 



5.1 80287 NUMERIC COPROCESSOR INTERFACE 

The 80287 is described in this section only as it relates to the 80386, For a complete functional 
description of the 80287, see the 80287 Data Sheet. 



5.1.1 80287 Connections 

The connections between the 80386 and the 80287 are shown in Figure 5-1. These connec- 
tions are made as follows: 

• The 80287 BUSY#, ERROR#, and PEREQ outputs are connected to corresponding 80386 
inputs. 

• The 80287 RESET input is connected to the 82384 RESET output. 

• The 80287 Numeric Processor Select chip-select inputs (NPS1# and NPS2) are connected 
to the latched M/IO# and A3 1 outputs, respectively. For coprocessor cycles, M/IO# is 
always low; A31, high. 

• The 80287 Command inputs (CMDl and CMDO) differentiate data from commands. 
These inputs are connected to ground and the latched A2 output, respectively. The 80386 
outputs address 800000F8H when writing a command, address 800000FCH when writing 
or reading data. 

• The lower half of the data bus connects to the 16 data bits of the 80287. The 80386 
transfers data to and from the 80287 only over the D15-D0 lines. 

• The 80287 Numeric Processor Read (NPRD#) and Numeric Processor Write (NPWR#) 
inputs are connected to I/O read and write signals from local bus control logic. The 
configuration of this logic depends on the overall system. 

• The 80287 Processor Extension Acknowledge (PEACK#) input is pulled high. In an 80286 
system, the 80286 generates PEACK# to disable the PEREQ output of the 80287 so that 
extra data is not transferred. Because the 80386 knows the length of the operand and will 
not transfer extra data, PEACK# is not needed or used in 80386 systems. 



5.1.2 80287 Bus Cycles 

When the 80386 encounters a coprocessor instruction, it automatically generates one or more 
I/O cycles to I/O addresses 800000F8H and 800000FCH. The 80386 performs all neces- 
sary bus cycles to memory and transfers data to and from the 80287 on the lower half of the 
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Figure 5-1. 80386 System with 80287 Coprocessor 

data bus. The 80386 automatically converts 32-bit memory transfers to 16-bit 80287 trans- 
fers and vice versa. Because the 80386 automatically performs 80287 transfers as 16 bits 
wide, the BS16# input of the 80386 does not need to be activated for transfers to and from 
the 80287. 



Bus control logic must guarantee 80287 timing requirements, particularly the minimum 
command inactive time (Tcmdi)- Depending on the design of the bus controller, command 
delays may be required. 
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5.1.3 80287 Clock Input 

The 80287 can operate from the CLK or CLK2 output of the 82384 or a dedicated clock 
oscillator. To operate the 80287 from CLK or CLK2, the Clock Mode (CKM) pin of the 
80287 must be tied to ground. In this configuration, the 80287 divides the system clock 
frequency internally by three. 

The CKM pin of the 80287 is tied high to operate the 80287 from a dedicated MOS-level 
clock. In this configuration, the 80287 does not internally divide the clock frequency; it 
operates directly from the external clock. An 8284A clock driver and an appropriate crystal 
can be used to provide the 80287 v^ith the desired clock frequency. 



5.2 80387 NUMERIC COPROCESSOR INTERFACE 

The 80387 achieves significant enhancements in performance and instruction capabilities 
over the 80287. It runs at internal clock rates of up to 16 MHz. To achieve maximum speed, 
the interface with the 80386 is synchronous and includes a full 32-bit data bus. Detailed 
information on other 80387 enhancements can be found in the 80387 Data Sheet. 

The 80387 is designed to run either fully synchronously or pseudosynchronously with the 
80386. In the pseudosynchronous mode, the interface logic of the 80387 runs with the clock 
signal of the 80386, whereas internal logic runs with a different clock signal. 



5.2.1 80387 Connections 

The connections between the 80386 and the 80387 are shown in Figure 5-2 and are described 
as follows: 

• The 80387 BUSY#, ERROR#, and PEREQ outputs are connected to corresponding 80386 
inputs. 

• The 80387 RESETIN input is connected to the 82384 RESET output. 

• The 80387 Numeric Processor Select chip-select inputs (NPS1# and NPS2) are connected 
directly to the 80386 M/IO# and A31 outputs, respectively. For coprocessor cycles, 
M/IO# is always low; A3 1, high. 

• The 80387 Command (CMDO#) input differentiates data from commands. This input is 
connected directly to the 80386 A2 output. The 80386 outputs address 8O0000F8H when 
writing a command or reading status, address 800000FCH when writing or reading data. 

• All 32 bits (D3 1-DO) of the 80386 data bus connect directly to the data bus of the 80387. 
Because the data lines are connected directly, any local data bus transceivers must be 
disabled when the 80386 reads data from the 80387. 

® The 80387 READY#, ADS#, and W/R# inputs are connected to the corresponding pins 
on the 80386. READY# and ADS# are used by the 80387 to track bus activity and 
determine when W/R#, NPS1#, NPS2, and Status Enable (STEN) can be sampled. 
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Figure 5-2. 80386 System with 80387 Coprocessor 
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STEN is an 80387 chip select and can be pulled high. If multiple 80387s are used by the 
same 80386, STEN can be used to activate one 80387 at a time. 

Ready Out (READYO#) is an optional output that can be used to generate the wait 
states required for a coprocessor. External logic can generate these wait states easily as 
well, because the number of wait states is constant. 



5.2.2 80387 Bus Cycles 

When the 80386 encounters a coprocessor instruction, it automatically generates one or more 
I/O cycles to addresses 800000F8H and 800000FCH. The 80386 will perform all necessary 
bus cycles to memory and transfer data to and from the 80387. All 80387 transfers are 
32 bits wide. If the memory subsystem is only 16 bits wide, the 80386 automatically performs 
the necessary conversion before transferring data to or from the 80387. 

Read cycles (transfers from the 80387 to the 80386) require at least one wait state, whereas 
write cycles to the 80387 require no wait states. This requirement is automatically reflected 
in the state of the READYO# output of the 80387, which can be used to generate the 
necessary wait state. 



5.2.3 80387 Clock Input 

The 80387 can be operated in two modes. In either mode, the CLK2 signal must be connected 
to the 386CLK2 input of the 80387 because the interface to the 80386 is always synchron- 
ous. The state of the 80387 CKM input determines its mode: 

• In synchronous mode, CKM is high and the 387CLK2 input is not connected. The 80387 
operates from the CLK2 signal. Operation of the 80387 is fully synchronous with that of 
the 80386. 

• In pseudo-synchronous mode, CKM is low and a frequency source for the 387CLK2 input 
must be provided. Only the interface logic of the 80387 is synchronous with the 80386. 
The internal logic of the 80387 operates from the 387CLK2 clock source, whose frequency 
may be 10/16 to 16/10 times the speed of CLK2. Figure 5-3 depicts pseudo- 
synchronous operation. 



5.3 LOCAL BUS ACTIVITY WITH THE 80287/80387 

Both 80287 and 80387 coprocessors use two distinct methods to interact with the 80386: 

• The 80386 initiates coprocessor operations during the execution of a coprocessor instruc- 
tion (an ESC instruction). These interactions occur under program control. 

• The coprocessor uses the PEREQ signal to request the 80386 to initiate operand transfers 
to or from system memory. These operand transfers occur when the 80287/80387 requests 
them; thus, they are asynchronous to the instruction execution of the 80386. 
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Figure 5-3. Pseudo-Synchronous Interface 



When the 80386 executes an ESC instruction that requires transfers of operands to or from 
the coprocessor, the 80386 automatically sets an internal memory address base register, 
memory address limit register, and direction flag. The coprocessor can then request operand 
transfers by driving PEREQ active. These requests occur only when the coprocessor is 
executing an instruction (when BUSY# is active). 

Two, three, four or five bus cycles may be necessary for each operand transfer. These cycles 
include one coprocessor cycle plus one of the following: 

• One memory cycle for an aligned operand 

• Two memory cycles for a misaligned operand 

• Two or three memory cycles for misaligned 32-bit operands to 16-bit memory 

• Four memory cycles for misaligned 64-bit operands to 16-bit memory 

Data transfers for the coprocessor have the same bus priority as programmed data transfers. 



5.4 DESIGNING AN UPGRADABLE 80386 SYSTEM 

It is relatively simple to design an 80386 system with an 80287 that may be later upgraded 
to an 80387. The advantage of such a system is that two performance levels may be addressed 
by one system at minimal additional cost. 
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5.4.1 80287/80387 Recognition 

The 80386 samples its ERROR# input during initialization (after RESET goes low and 
before execution of the first instruction) to determine the type of coprocessor present. The 
80387 holds its ERROR# output low after reset, whereas the 80287 holds its ERROR# 
output high. Therefore, if the 80386 samples ERROR# low, it assumes that an 80387 is 
present. If it samples ERROR# high, it assumes that either an 80287 is present or that a 
coprocessor is not used. 

If the 80386 determines that an 80387 is present, the 80386 must be programmed to execute 
the FNINIT instruction to reset the ERROR# output of the 80387 before any coprocessor 
transaction takes place. Software can determine the coprocessor type by testing the ET bit 
in the machine status word. If ET= 1, the 80387 is present. 

If the 80386 determines that either an 80287 is present or a coprocessor is not used, it must 
then execute a routine to determine the presence of an 80287 in order to set its internal 
status. Figure 5-4 shows an example of a recognition routine. In order to use this routine, 
the designer must connect a puUup resistor to at least one of the lower eight bits of the data 
bus if a coprocessor is not used. 

In the example routine, the 80386 assumes that the 80287 is present, and executes an 
FNINIT instruction. Following the FNINIT instruction, the 80386 reads the 80287 status 
word. If an 80287 is present, the lower eight bits of this word (the exception flags) are all 
zeros. If an 80287 is not present, these data lines are floating. If a puUup resistor is connected 
to at least one of these lines, the absence of an 80287 is confirmed by at least one high bit 
in the lower eight bits of the status word. The routine then sets or resets the Emulate Copro- 
cessor (EM) bit of the CRO register (shown in Figure 5-5) of the 80386, depending on 
whether or not an 80287 is present. 



initialization routine to detect an 80287 Numeric Processor 



FND 287 ! 



FNINIT 

FSTSW AX 

OR AL , AL 



JZ 



GOT 287 



SMSW AX 

OR AX , 04H 

LMSU AX 

JMP CONTINUE 



G0T_287: SMSW 
OR 
LMSW 

CONTINUE: 



AX 

AX , 2H 

AX 



initialize Numeric Processor 

retrieve 80287 status word 

test low-byte 80287 exception flags 

if all zero, then 80287 present and 

properly initialized 

if not all zero, then 80287 absent. 

branch if 80287 present 

No numeric processor 

set EM bit in machine status word 

to enable software emulation of 80287 



Numeric Procesor present 

set MP bit in machine status word 

to permit normal 80287 operation 



and off we go. 



Figure 5-4. Routine to Detect 80287 Presence 
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iOii INDICATES INTEL RESERVED: DO NOT DEFINE. 



PG: PAGING ENABLE 

ET: PROCESSOR EXTENSION TYPE 

TS: TASK SWITCHED 

EM: EMULATE COPROCESSOR 

MP: MONITOR COPROCESSOR 

PE: PROTECTION ENABLE 



Figure 5-5. 80386 Machine Control Register (CRO) 

5.4.2 80387 Emulator 

The 80387 emulator circuit makes a 10-MHz 80287 appear to the 80386 as an 80387. The 
schematic is shown in Figure 5-6. An 80387 socket (80387 PGA Adapter) is connected to 
the 80386 (connections not shown) as described earlier in this chapter. 

The 80287 sends signals to the 80386 through the socket. The inputs coming to the socket 
from the 80386 are decoded by the PAL16L8 (Math Control) to provide the buffered CMDO, 
NPRD#, and NPWR# inputs for the 80287. The PAL equations for the Math Control PAL 
are listed in Appendix B of this manual. 

The data Unes of the 80287 are connected to the lower half of the 80386 data bus through 
the socket; the BUSY#, ERROR#, and PEREQ signals are returned to the 80386 through 
the socket as well. Note that while this circuit allows the 80386 to use an 80387 interface 
with the 80287, the 80287 still performs only 16-bit data transfers. Therefore, during initial- 
ization, the ERROR# output of the 80287 is high to indicate the presence of an 80287, not 
an 80387. 
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Figure 5-6. 80387 Emulator Schematic 
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CHAPTER 6 
MEMORY INTERFACING 



The 80386 high-speed bus interface has many features that contribute to high-performance 
memory interfaces. This chapter outlines approaches to designing memory systems that utilize 
these features, describes memory design considerations, and lists a number of useful examples. 
The concepts illustrated by these examples apply to a wide variety of memory system 
implementations. 



6.1 MEMORY SPEED VERSUS PERFORMANCE AND COST 

In a high-performance microprocessing system, overall system performance is linked to the 
performance of memory subsystems. Most bus cycles in a typical microprocessing system 
are used to access memory because memory is used to store programs as well as the data 
used in processing. 

To realize the performance potential of the 80386, a system must use relatively fast memory. 
A high-performance processor coupled with low-performance memory provides no better 
throughput than a less expensive low-performance processor. Fast memory devices, however, 
cost more than slow memory devices. 

The cost-performance tradeoff can be mediated by partitioning functions and using a combi- 
nation of both fast and slow memories. If the most frequently used functions are placed in 
fast memory and all other functions are placed in slow memory, high performance for most 
operations can be achieved at a cost significantly less than that of a fast memory subsystem. 
For example, in a RAM-based system that uses read-only memory devices primarily during 
initialization, the PROM or EPROM can be slow (requiring three to four wait states) and 
yet have little effect on system performance. RAM memory can also be partitioned into fast 
local memory and slower system memory. Other performance considerations are described 
in detail in Chapter 4. 

The relationship between memory subsystem performance and the speed of individual memory 
devices is determined by the design of the memory subsystem. Cache systems, which couple 
a small cache memory with a larger main memory, are described in Chapter 7. Basic memory 
interfaces are described in this chapter. 



6.2 BASIC MEMORY INTERFACE 

The high performance and flexibility of the 80386 local bus interface plus the availability of 
programmable and semi-custom logic (programmable logic arrays, for example) make it 
practical to design custom bus control logic that meets the requirements of a particular 
system. Standard logic components can generate the bus control signals needed to interface 
the 80386 with memory and I/O devices. The basic memory interface is discussed in this 
chapter; the basic I/O interface is presented in Chapter 8. 
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The block diagram of the basic memory interface is shown in Figure 6-1. The bus control 
logic provides the control signals for the address latches, data buffers, and memory devices; 
it also returns READY# active to end the 80386 bus cycle and NA# to control address 
pipelining. The address decoder generates chip-select signals and the BS16# signal based on 
the address outputs of the 80386. This interface is suitable for accessing ROMs, EPROMs, 
and static RAMs (SRAMs). 



6.2.1 PAL Devices 

Many design examples in this manual use PAL (Programmable Array Logic) devices, which 
can be programmed by the user to implement random logic. A PAL device can be used as a 
state machine or a signal decoder, for example. The advantages of PALs include the 
following: 

• Programmability allows the PAL functions to be changed easily, simplifying prototype 
development. 

• The designer determines PAL pinout and can simplify the board layout by moving signals 
as required. 
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Figure 6-1. Basic Memory interface Block Diagram 
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• PALs are inexpensive compared to dedicated bus controllers. 

• Once a PAL design has been tested, Hard Array Logic (HAL) devices, which are mask- 
programmed PALs, can be used in production quantities (several thousand units). 

PALs also have the following disadvantages: 

• Pin counts or speeds of available PALs can restrict some designs. 

• Most PALs do not have buried (not connected to outputs) state registers; therefore, in 
state-machine implementations, registered output pins must be used to store the current 
state. 

• The drive capability of PALs may be insufficient for some applications. In these cases, 
buffering is required. 

A PAL device consists logically of a programmable AND array whose output terms feed a 
fixed OR array. Any sum-of-products equation, within the Umits of the number of PAL 
inputs, outputs, and equation terms, can be realized by specifying the correct AND array 
connections. Figure 6-2 shows an example of two PAL equations and the corresponding logic 
array. Note that every horizontal line in the AND array represents a multi-input AND gate; 
every vertical line represents a possible input to the AND gate. The X at the intersection of 
a horizontal line and a vertical line represents a connection from the input to the AND gate. 

Programming a PAL device consists of determining where the Xs must be placed in the 
AND array. This task is simplified by the use of a PAL assembler program. Such a program 
accepts input in the form of sum-of-products equations. The assembled code is then applied 
to a PAL device using a standard PROM programmer equipped with a special PAL 
enhancement. 

The following conventions apply to TTL and PAL devices described in this section: 

• TTL devices are specified by number (function), but not by family (speed). Virtually any 
family of a device can be used if it meets the performance requirements of the applica- 
tion. For example, a 74x00 device might be implemented with a 74F00 or 74AS00. 
Generally, the F and AS families provide the highest performance. 

• PAL devices are specified by part number. A PAL part number generally consists of a 
number, a letter, and a second number, and is interpreted as shown in Figure 6-3. PALs 
are manufactured for a number of performance levels. Standard PALs are suitable unless 
otherwise specified. 



6.2.2 Address Latch 

Latches maintain the address for the duration of the bus cycle and are necessary to pipeline 
addresses because the address for the next bus cycle appears on the address lines before the 
current cycle ends. In this example, 74x373 latches are used. Although the 80386 can be 
run without address pipelining to eliminate the need for address latching, the system will 
usually run less efficiently. 
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Sample equations: 

/Q = A'/B 

+ A* /R 
+ /A'B'R 

/R:= A*/R 

+ /B 

Sample block diagram: 
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f^ 



t}^ 



G30107 



Figure 6-2. PAL Equation and Implementation 

The 74x373 Latch Enable (LE) input is controlled by the Address Latch Enable (ALE or 
ALE#) signal from the bus control logic that goes active at the start of each bus cycle. The 
74x373 Output Enable (OE#) is always active. 



6.2.3 Address Decoder 

In this example, the address decoder, which converts the 80386 address into chip-select 
signals, is located before the address latches. In general, the decoder may also be placed 
after the latches. If it is placed before the latches, the chip-select signal becomes valid as 
early as possible but must be latched along with the address. Therefore, the number of address 
latches needed is determined by the location of the address decoder as well as the number 
of address bits and chip-select signals required by the interface. The chip-select signals are 
routed to the bus control logic to set the correct number of wait states for the accessed 
device. 
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16R8 






Number of Outputs 




Output Type* 




Number of Internal and External Inputs 




'Output types are designated as follows: 




H Active High 




L Active Low 




C Complementary 




R Registered 




X Exclusive-OR Registered 




A Arithmetic Registered 



Figure 6-3. PAL Naming Conventions 

The decoder consists of two one-of-four decoders, one for memory address decoding and one 
for I/O address decoding. In general, the number of decoders needed depends on the memory 
mapping complexity. In this basic example, the A3 1 output is sufficient to determine which 
memory device is to be selected. 



6.2.4 Data Transceiver 

Standard 8-bit transceivers (74x245, in this example) provide isolation and additional drive 
capability for the 80386 data bus. Transceivers are necessary to prevent the contention on 
the data bus that occurs if some devices are slow to remove read data from the data bus 
after a read cycle. If a write cycle follows a read cycle, the 80386 may drive the data bus 
before a slow device has removed its outputs from the bus, potentially causing reliability 
problems. Transceivers can be omitted only if the data float time of the device is short enough 
and the load on the 80386 data pins meets device specifications. 

A bus interface must include enough transceivers to accommodate the device with the most 
inputs and outputs on the data bus. Normally, 32-bit-wide memories, which require four 
8-bit transceivers, are used in 80386 systems. 

The 74x245 transceiver is controlled through two input signals: 

• Data Transmit/Receive (DT/R#) — When high, this input enables the transceiver for a 
write cycle. When low, it enables the transceiver for a read cycle. This signal is just a 
latched version of the 80386 W/R# output. 

• Data Enable (DEN#) — When low, this input enables the transceiver outputs. This signal 
is generated by the bus control logic. 
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6.2.5 Bus Control Logic 

Bus control logic is shown in Figure 6-4. The bus controller is implemented in two PALs. 
One PAL (PAL-1) follows the 80386 bus cycles and generates the overall bus cycle timing. 
The second PAL (PAL-2) generates most of the bus control signals. The equations for these 
PALs are listed in Appendix A of this manual. 

The bus controller decodes the 80386 status outputs (W/R#, M/IO#, and D/C#) and 
activates a command signal for the type of bus cycle requested. The command signal corre- 
sponds to the bus cycle types (described in Chapter 3) as follows: 

• Memory data read and memory code read cycles generate the Memory Read Command 
(MRDC#) output. MRDC# commands the selected memory device to output data. 

• I/O read cycles generate the I/O Read Command (IORC#) output. IORC# commands 
the selected I/O device to output data. 

• Memory write cycles generate the Memory Write Command (MWTC#) output. MWTC# 
commands the selected memory device to receive the data on the data bus. 

• I/O write cycles generate the I/O Write Command (IOWC#) output. IOWC# commands 
the selected memory device to receive the data on the data bus. 

• Interrupt-acknowledge cycles generate the Interrupt Acknowledge (INTA#) output, which 
is returned to the 8259A Interrupt Controller. The second INTA cycle commands the 
8257A to place the interrupt vector on the bus. 

Figure 6-5 shows the timings of bus control signals for various memory accesses. 

The bus controller also controls the READY# input to the 80386 that ends each bus cycle. 
The PAL-2 bus control PAL counts wait states and returns READY# after the number of 
wait states required by the accessed device. The design of this portion of the bus controller 
depends on the requirements of the system; relatively simple systems need less wait-state 
logic than more complex systems. The basic interface described here uses a PAL device to 
generate READY#; other designs may use counters and/or shift registers. 

The bus controller generates one of two bus cycles depending on which memory is being 
accessed. Two inputs to PAL-1 (CSOWS and CSIWS) from the address decoder determine 
the bus control signal timings. Table 6-1 shows the number of wait states, the command 
delay time, and the data float time for each bus cycle. 

Table 6-1. Bus Cycles Generated by Bus Controller 



Chip-Select 


Cycle Type 


WAIT-STATES 


Command 
Delay 


Data-Float 


Pipelined 


UnPipelined 


CSOWS 


read 
write 



1 


1 
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1 CLK2 
1 CLK2 


2CLK2 


CS1WS 


any 
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2CLK2 


4CLK2 
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Figure 6-5. Bus Control Signal Timing 



Intel 



MEMORY INTERFACING 



6.2.6 EPROM interface 

Figure 6-6 shows the signal timing for bus cycles from an 80386 operating at 16 MHz to a 
27128-1 EPROM, which has a 1 50-nanosecond access time. Faster 110-nanosecond EPROMs 
are also available but in this design, they require the same number of wait states as the 
1 50-nanosecond EPROMs require. Timings for a 1 50-nanosecond SRAM are included for 
comparison. 

In the EPROM interface, the OE# input of each EPROM devices is connected directly to 
the MRDC# signal from the bus controller. The wait state requirement is calculated by 
adding up worst-case delays and comparing the total with the 80386 bus cycle time. 

The bus cycle timings can be calculated from the waveforms in Figure 6-6. In the following 
example, the timings for I/O accesses are calculated for CLK2 = 32 MHz and B-series 
PALs. All times are in nanoseconds. Check the most recent 80386 Data Sheet to confirm 
all parameter values. 

tAR: Address stable before Read (MRDC# fall) 

(1 X CLK2 period)- PAL RegOut Max- Latch Enable Max 

- PAL RegOut Min 

(1 X 31.25) - 12 - 11.5 

+ 

= 7.75 nanoseconds 

tRR: Read (MRDC#) pulse width 

(4 X CLK2 period) - PAL RegOut Max + PAL RegOut Min 
(4x31.25) -12 +0 

= 113 nanoseconds 

tRA: Address hold after Read (MRDC# rise) 

(0 X CLK2 period) - PAL RegOut Max + PAL RegOut Min 

+ Latch Enable Min 

(0x31.25) - 12 +0 

+ 5 

= — 7 nanoseconds (This is acceptable because latched addresses are held for at 
least as long as the end of the bus cycle.) 

tAD: Data delay from Address 

(6 X CLK2 period) - PAL RegOut Max - Latch Enable Max 

- xcvr. prop. Min — 80386 Data Setup Min 
(6x31.25) - 12 - 11.5 

- 6 -10 

= 148 nanoseconds 
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Figure 6-6. 150-Nanosecond EPROM Timing Diagram 
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tRD: Data delay from Read (MRDC#) 

(4 X CLK2 period) — PAL RegOut Max — xcvr. prop Min 

- 80386 Data Setup Min 

(4x31.25) - 12 - 6 

- 10 

= 97 nanoseconds 

tDF: read (MRDC# rise) to Data Float 

(4 X CLK2 period) - PAL RegOut Max + PAL RegOut Min 

+ xcvr. Enable Min 

(4x31.25) - 12 -f- 

+ 3 

= 116 nanoseconds 

To pipeline the address outputs for sequential EPROM accesses, the address decoder logic 
must generate the Next Address (NA#) signal. Note that the initial EPROM cycle follow- 
ing the idle cycle cannot be address pipelined because there is no previous bus cycle. In 
addition, the bus cycle following the last EPROM access is pipelined regardless of which 
device it accesses, because the address is output before the bus cycle destination can be 
determined. 

6.2.7 SRAM Interface 

In the SRAM interface, the OE# input of each SRAM device is connected to the MRDC# 
signal from the bus controller; the WE# input of each SRAM device is driven by the M WTC# 
signal. Because it is possible to write to only some bytes of a doubleword, the MWTC# 
signal cannot connect directly to the WE# inputs. Each WE# input must be qualified by the 
latched 80386 byte-enable signals (BE3#-BE0#). 

Figure 6-7 shows the signal timing for bus cycles to an Intel SRAM, which has a 
100-nanosecond access time. The timing is essentially the same as for an EPROM. 

The bus cycle timings can be calculated from the waveforms in Figure 6-7. In the following 
example, the timings for I/O accesses are calculated for CLK2 = 32 MHz and B-series 
PALs. All times are in nanoseconds. Check the most recent 80386 Data Sheet to confirm 
all parameter values. 

tAR: Address stable before Read (MRDC# fall) 
tAW: Address stable before Write (MWTC# fall) 

(1 X CLK2 period) -- PAL RegOut Max - Latch Enable Max 

+ PAL RegOut Min 

(1x31.25) - 12 - 11.5 

+ 

= 7.75 nanoseconds 
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Figure 6-7. 100-Nanosecond SRAM Timing Diagram 
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tRR: Read (MRDC#) pulse width 

(3 X CLK2 period) - PAL RegOut Max + PAL RegOut Min 
C3x3L25) - 12 + 

= 81.75 nanoseconds 

tWW: Write (MWTC#) pulse width 

(4 X CLK2 period) - PAL RegOut Max+ PAL RegOut Min 
(4x31.25) - 12 + 

= 113 nanoseconds 

tRA: Address Hold after Read (MRDC# rise) 

(0 X CLK2 period) - PAL RegOut Max + PAL RegOut Min 

+ Latch Enable 

(0x31.25) - 12 +0 

+ 5 

= — 7 nanoseconds (This is acceptable because latched addresses are held for at 
least as long as the end of the bus cycle.) 

tWA: Address hold after Write (MWTC# rise) 

(1 X CLK2 period) - PAL RegOut Max + PAL RegOut Min 

+ Latch Enable Min 

(1 X 31.25) -12 +0 

+ 5 

= 24.25 nanoseconds 
tAD: Data delay from Address 

(4 X CLK2 period) - PAL RegOut Max - Latch Enable Max 

- xcvr. prop. Min — 80386 Data Setup Min 
(4x31.25) - 12 - 11.5 

- 6 - 10 

= 85.5 nanoseconds 
tRD: Data delay from Read (MRDC#) 

(3 X CLK2 period) — PAL RegOut Max — xcvr. prop Min 

- 80386 Data Setup Min 

(3x31.25) - 12 - 6 

~ 10 

= 65.75 nanoseconds 
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tDF: read (MRDC# rise) to Data Float 

(2 X CLK2 period) - Pal RegOut Max + PAL RegOut Min 

+ xcvr. Enable Min 

(2x31.25) -12 +0 

+ 3 

= 47.5 nanoseconds 

tDW: Data setup before write (MWTC# rise) 

(3 X CLK2 period) - PAL RegOut Max - xcvr. Enable Max 

+ PAL RegOut Min 

(3x31.25) - 12 - 11 

+ 

= 70.75 nanoseconds 

tWD: Data hold after write (MWTC# rise) 

(1 X CLK2 period) - PAL RegOut Max + PAL RegOut Min 

+ xcvr. Disable Min 

(1x31.25) - 12 +0 +2 

= 21.25 nanoseconds 

6.2.8 16-Bit Interface 

The use of a 16-bit data bus can be advantageous for some systems. Memory implemented 
as 16-bits wide rather than 32-bits wide reduces chip count. I/O addresses located at word 
boundaries rather than doubleword boundaries can be software compatible with some systems 
that use 16-bit microprocessors. 

For example, if BS16# is asserted for EPROM accesses, only two byte- wide EPROMs are 
needed. Overall performance is reduced because 32-bit data accesses and all code prefetches 
from the EPROMs are slower (requiring two bus cycles instead of one). However, this 
reduction is acceptable in certain applications. A system that uses EPROMs only for power- 
on initialization and runs programs entirely from SRAM or DRAM has only a power-on 
time increase over the 32-bit EPROM system; its main programs run at the same speed as 
the 32-bit system. 

The 80386 BS16# input directs the 80386 to perform data transfers on only the lower 
16 bits of the data bus. In systems in which 16-bit memories are used, the address decoder 
logic must generate the BS16# signal for 16-bit accesses. Since NA# cannot be asserted 
during a bus cycle in which BS16# is asserted (because the current address may be needed 
for additional cycles), the decoder logic should also guarantee that the NA# signal is not 
generated. When the 80386 samples BS16# active and NA# inactive, it automatically 
performs any extra bus cycles necessary to complete a transfer on a 16-bit bus. The 80386 
response is determined by the size and alignment of the data to be transferred, as described 
in Chapter 3. 
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6.3 DYNAMIC RAM (DRAM) INTERFACE 

This section presents a dynamic RAM (DRAM) memory subsystem design that is both cost- 
effective and fast. The design can be adapted for a wide variety of speed and system require- 
ments to provide high throughput at minimum cost. 

6.3.1 Interleaved Memory 

DRAMs provide relatively fast access times at a low cost per bit; therefore, large memory 
systems can be created at low cost. However, DRAMs have the disadvantage that they require 
a brief idle time between accesses to precharge; if this idle time is not provided, the data in 
the DRAM can be lost. If back-to-back accesses to the same bank of DRAM chips are 
performed, the second access must be delayed by the precharge time. To avoid this delay, 
memory should be arranged so that each subsequent memory access is most likely to be 
directed to a different bank. In this configuration, wait time between accesses is not required 
because while one bank of DRAMs performs the current access, another bank precharges 
and will be ready to perform the next access immediately. 

Most programs tend to make subsequent accesses to adjacent memory locations during code 
fetches, stack operations, and array accesses, for example. If DRAMs are interleaved (i.e., 
arranged in multiple banks so that adjacent addresses are in different banks), the DRAM 
precharge time can be avoided for most accesses. With two banks of DRAMs, one for even 
32-bit doubleword addresses and one for odd doubleword addresses, all sequential 32-bit 
accesses can be completed without waiting for the DRAMs to precharge. 

Even if random accesses are made, two DRAM banks allow 50 percent of back-to-back 
accesses to be made without waiting for the DRAMs to precharge. The precharge time is 
also avoided when the 80386 has no bus accesses to be performed. During these idle bus 
cycles, the most recently accessed DRAM bank can precharge so that the next memory 
access to either bank can begin immediately. 

The DRAM memory system design described here uses two interleaved banks of DRAMs. 
The DRAM controller keeps track of the most recently accessed bank in order to guarantee 
the precharge time for both banks while allowing memory accesses to begin as soon as 
possible. 

6.3.2 DRAM Memory Performance 

Table 6-2 shows the performance that can be obtained using this DRAM design with a 
variety of processor and DRAM speeds. Performance is indicated by the number of wait 
states per bus cycle (the number of CLK cycles in addition to the two-CLK minimum time 
required to complete the access). 

The performance for each processor and DRAM speed combination is given for both the 
case of an access to the opposite bank of interleaved memories, in which no precharge time 
is required, and the case of an access to the same bank, in which the precharge time is 
factored in. 
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Table 6-2. DRAM Memory Performance 



80386 
Clock Rate 


DRAM 

Access Time 

(Nanoseconds) 


Bus Cycle Wait-States 


Interleaved 
Piped:Unpiped 


Same Bank 


12 MHz 
12 MHz 
16 MHz 
16 MHz 
16 MHz 


120 
200 
80 
100 
150 


0* 
1 

0* 
0* 

1 


1 * 

2 

1 * 
1 * 
2 


1 * 
3 

1 * 
V 
3 



*Add one additional wait-state to these times for write accesses. 

Note: The numbers for the 1 00-nanosecond DRAM are based on the assumption that no data transceivers 
are used. 

The number of wait states required for interleaved accesses is based on the assumption that 
the address for the next access is pipelined. For cycles in which the address is not pipelined, 
one extra wait-state must be added to the number in Table 6-2. This requirement applies to 
all cycles that follow an idle bus state because these cycles can never be pipelined. 

The number of wait states for same-bank accesses applies only to back-to-back cycles (without 
intervening idle bus time) to the same bank of DRAMs. Because the controller must allow 
the DRAMs to precharge before starting the access, address pipelining does not speed up 
the same-bank cycle; the number of wait states is identical with or without address 
pipelining. 

The numbers in Table 6-2 are affected by DRAM refresh cycles. All DRAMs require periodic 
refreshing of each data cell to maintain the correct voltage levels. An access to a memory 
cell, called a refresh cycle, accomplishes the refresh. During one of these periodic refresh 
cycles, the DRAM cannot respond to processor requests. 

Although the distributed DRAM refresh cycles occur infrequently, they can delay the current 
access so that the current access requires a total of up to four wait states (for the cases 
marked with an asterisk (*)) or eight wait states (for the other cases). 



6.3.3 DRAM Controller 



The performances shown in Table 6-2 are derived from two DRAM controller designs that 
differ in the number of CLKs they allow for read/refresh access and precharge times. The 
two designs are designated by the number of CLKs required for a read cycle. The 2-CLK 
design is used for the cases in Table 6-2 that are marked with an asterisk (*); the 3-CLK 
design is used for the other cases. 
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6.3.3.1 3-CLK DRAM CONTROLLER 

Figure 6-8 shows a schematic of the 3-CLK DRAM controller. The DRAM array contains 
two banks of 32-bit-wide DRAMs. The top and bottom halves of the pictured array repre- 
sent the two banks, which are each divided vertically along the four bytes for each 
doubleword. 

The DRAM chips used to create the DRAM banks can be of any length (N), and they can 
be either one bit or four bits wide. If Nxl DRAM chips are used, 64 chips are required for 
the two banks; if Nx4 DRAM chips are used, only 16 chips are required. The banks in 
Figure 6-8 are made from sixteen 64Kx4 DRAMs, but another type of DRAM can be 
substituted easily. 

Two Row Address Strobe (RAS) signals are generated by the controller, one for each bank. 
The top bank is activated by RASO# and contains the DRAM memory locations for which 
the 80386 address bit A2 is low. The bottom bank is activated by RAS1#, which corresponds 
to 80386 addresses for which A2 is high. 

Four Column Address Strobe (CAS) signals are used, one for each byte of the 80386 data 
bus. These CAS signals are shared by both banks. The 80386 Byte Enable signals 
(BE3#-BE0#) map directly to the CAS signals (CAS3#-CAS0#). CASO# is mapped directly 
from BEO# and enables the least-significant byte (D7-D0). Similarly, CAS3# is mapped 
directly from BE3# and enables the most-significant byte (D31-D24). 

Each of the 32 data lines of the 80386 are connected to one DRAM chip from each bank. 
If Nxl DRAMs are used, the corresponding data line is connected to both the Din and Dout 
pins. If Nx4 DRAMs are used, each data Hne is connected only to the corresponding 
I/O pin. 

The Write Enable (WE#) signal and the multiplexed address signals are connected to every 
DRAM chip in both banks. Nx4 DRAMs also require an Output Enable (0E#) signal for 
every DRAM chip in both banks. 

A single WE# control signal and four CAS control signals ensure that only those DRAM 
bytes selected for a write cycle are enabled. All other data bytes maintain their outputs in 
the high-impedance state. A common design error is to use a single CAS# control signal and 
four WE# control signals, using the WE# signals to write the DRAM bytes selectively in 
write cycles that use fewer than 32 bits. However, although the selected bytes are written 
correctly, the unselected bytes are enabled for a read cycle. These bytes output their data to 
the unselected bits of the data bus while the data transceivers output data to every bit of the 
data bus. When two devices simultaneously output data to the same bus, reliability problems 
and even permanent component damage can result. Therefore, a DRAM design should use 
CAS signals to enable bytes for a write cycle. 

DRAMs require both the row and column addresses to be placed sequentially onto the 
multiplexed address bus. A set of 74F258 multiplexers accomplishes this function. 
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Figure 6-8. 3-CLK DRAM Controller Schematic 
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Four 74F245 octal transceivers buffer the DRAM from the data bus. Most DRAMs used in 
the 3-CLK design require these transceivers to meet the read-data float time. When a DRAM 
read cycle is followed immediately by an 80386 write cycle, the 80386 drives its data bus 
one CLK2 period after the read cycle completes. If the data transceivers are omitted, the 
RAS inactive delay plus the DRAM output buffer turn-off time (t-OFF) must be less than 
a CLK2 period to avoid data bus contention. 

PALs are used to monitor the 80386 status signals and generate the appropriate control 
signals for the DRAM, multiplexer, and transceivers. PAL codes and pin descriptions for 
the 3-CLK design are listed in Appendix C of this manual. 

The DRAM State PAL performs the following functions: 

• Monitors the 80386 DRAM chip-select logic 

• Receives DRAM refresh requests and responds with the necessary DRAM cycles 

• Keeps track of DRAM banks requiring precharge time 

A DRAM read or write access is requested when all the chip-select signals of the DRAM 
State PAL are sampled active simultaneously. These signals become active when all of the 
following conditions exist at once: 

• M/IO#, W/R#, and D/C# outputs of the 80386 indicate either a memory read, memory 
write, or code fetch. 

• The bus is idle or the current bus cycle is ending (READY# active). 

• ADS# is active. 

• A31 is low (in this design, the lower half (two gigabytes) of 80386 memory space is 
mapped to the DRAM controller). 

If the DRAM controller is not already performing a cycle, it begins the access immediately. 
However, if the DRAM controller is performing a refresh cycle, or if it is waiting for the 
DRAM bank to precharge, the request is latched and performed when the controller is not 
busy. 

The DRAM Control PAL generates the majority of the DRAM control signals. The Refresh 
Interval Counter PAL is a timer that generates refresh requests at the necessary intervals. 
The Refresh Address Counter PAL maintains the next refresh address. Both the Refresh 
Interval Counter PAL and the Refresh Address Counter PAL are simple enough to be 
replaced by TTL counter chips; however, the use of PALs reduces the total chip count. If 
there is a spare timer or counter in the system, it can be used to replace one or both of these 
PALs. 

Figure 6-9 shows the timing of DRAM control signals for the 3-CLK design for the follow- 
ing five sequential DRAM cycles: 

1. Read cycle 

2. Write cycle to the opposite bank (no precharge) 
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Figure 6-9. 3-CLK DRAM Controller Cycles 
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3. Read cycle to that same bank (requires precharge) 

4. Refresh cycle (always requires precharge) 

5. Read cycle (cycle after refresh always requires precharge) 

During a normal DRAM access, only the RAS signal that corresponds to the selected bank 
is activated. During a refresh cycle, both RAS signals are activated. During write cycles, 
only the CAS signals corresponding to the enabled bytes are activated. During read cycles, 
all CAS signals are enabled. 

6.3.3.2 2-CLK DRAM CONTROLLER 

Figure 6-10 is a schematic of the 2-CLK design, which provides zero wait-state operation 
for pipelined interleaved accesses. The design differs from the 3-CLK controller in several 
ways. 

Read and refresh cycles are completed in only two CLKs; write cycles require three CLKs 
to ensure that the 80386 write data is valid. 

In general, the PALs that generate RAS and CAS signals can be either registered or combi- 
natorial on the RAS and/or CAS outputs. If external registers are used, these PAL outputs 
must be combinatorial so that the output has time to set up the external register on the same 
CLK2 cycle. If the PAL outputs are used without external registers, the PAL outputs must 
be registered internally. When the CAS signals are registered internally, the DRAM Control 
PAL can sample and save the state of the Byte Enable (BE3#-BE0#) Hnes internally. When 
the CAS signals are registered externally, the BE3#-BE0# Hnes must be latched externally 
so that the DRAM Control PAL inputs maintain the valid byte enables. 

For the 2-CLK design, the RAS and CAS signals are registered externally. The delay (from 
CLK2) for these signals is reduced, and more time is available for the DRAMs to respond. 
If more drive is required on these signals, multiple TTL registers can be used, each driving 
a small group of RAS or CAS lines. For example, in a design using Nxl DRAMs, RASO# 
must drive 32 DRAMs. To reduce the worst-case skew (caused by the heavy loading), RASO# 
can be output on four register outputs, each of which drives eight DRAMs. 

In the 3-CLK design, the column address does not need to be latched because the Next 
Address (NA#) signal is not activated until after the CAS signals go active, so the 80386 
address remains valid for the memory access. Because a 2-CLK design has a shorter cycle 
time, NA# must be activated before the CAS signals go active to output the next address 
one CLK early. This early address necessitates a latch for the column addresses. In many 
cases, with a generalized LE control, this latch can be shared with the I/O subsystem, which 
usually must latch the address. 

In the 2-CLK design, NA# is generated from the DRAM State PAL outputs and is there- 
fore active in both the CLK2 cycle in which the 80386 samples NA# and the next CLK2 
cycle. However, the 80386 does not sample NA# active twice. Once the 80386 outputs the 
next address, the address must be valid for at least two CLKs before NA# is sampled again. 
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Figure 6-10. 2-CLK DRAM Controller Schematic 
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In the 2-CLK design, the four data transceivers are optional because fast DRAMs with 
short read-data-float times are used. The DRAM data pins and can be connected directly to 
the 80386 data bus. The strong drive capability of the 80386 data bus can handle the load 
of one DRAM from each bank plus a transceiver load for the other peripherals. 

PAL codes and pin descriptions for the 2-CLK design are listed in Appendix C of this manual. 
Figure 6-11 shows the timing of DRAM control signals for the 2-CLK design for the follow- 
ing five sequential DRAM cycles: 

1 . Read cycle 

2. Write cycle to the opposite bank (no precharge) 

3. Read cycle to that same bank (requires precharge) 

4. Refresh cycle (always requires precharge) 

5. Read cycle (cycle after refresh always requires precharge) 



6.3.4 DRAM Design Variations 

Some of the possible variations of the 2-CLK and 3-CLK designs are as follows: 

• Both the 3-CLK and 2-CLK designs can use any length DRAM in Nxl and Nx4 widths. 

• Both 3-CLK or 2-CLK designs can use the internal PAL registers or external TTL regis- 
ters on the RAS and/or CAS signals. A conservative design using Nxl DRAMs might 
externally register each RAS (which drives 32 DRAMs) and internally register each CAS 
(which drives only 16 DRAMs). 

Because internal registers have a greater maximum delay time and potentially less drive, the 
choice between registered PALs or external registers affects all of the DRAM timing 
parameters based on RAS and CAS. Some of the DRAM parameters are also affected by 
the minimum delay time of the internally registered PALs. Because PALs do not guarantee 
a minimum delay time, external TTL registers, which do guarantee a minimum delay time, 
can help meet these timing parameters, as well as provide greater drive capability. 

• Data transceivers are optional for both designs. If a data transceiver is used, the DRAM 
read access must meet the 80386 read-data setup time. If no data transceiver is used, the 
DRAM read-data-float time must not interfere with the next 80386 cycle, particularly if 
it is a write cycle, and the 80386 data pin loading must not be exceeded. 

• By including the column address latch and other circuitry, the DRAM controller can be 
adapted to run either 3-CLK or 2-CLK cycles depending on the speed (and cost) of 
DRAMs installed. To switch between the 3-CLK and 2-CLK controllers, the user should 
plug in a different set of DRAMs, a different DRAM State PAL, and a different DRAM 
Control PAL, and jumper the NA# logic. 

• The choice of chip-select logic in both of the designs is arbitrary. Other DRAM memory- 
mapping schemes can be implemented by modifying the address decoding to the DRAM 
State PAL chip-selects. 
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Figure 6-11. 2-CLK DRAM Controller Cycles 



iny 



MEMORY INTERFACING 



For a single DRAM bank rather than two, the user should tie the DRAM State PAL A2 
input low, leave RAS1# unconnected (only RASO# is used), and feed the 80386 address 
bit A2 into the address multiplexer. The DRAM State PAL equations can be modified 
to change the RAS1# output to duplicate the RASO# output for more drive capabiUty, 
and the A2 input can be used as another chip-select input. When only one bank is used, 
no accesses can be interleaved, and back-to-back accesses run with one wait state with 
the 2-CLK design and three wait states with the 3-CLK design (independent of address 
pipelining). 



6.3.5 Refresh Cycles 

All DRAMs require periodic refreshing of their data. For most DRAMs, periodic activation 
of each of the row address signals internally refreshes the data in every column of the row. 
Almost all DRAMs allow a RAS-only refresh cycle, the timing of which is the same as a 
read cycle, except that only the RAS signals are activated (no CAS signals), and all of the 
data pins are in the high impedance state. 

Both the 3-CLK and 2-CLK designs use RAS-only refresh. The address multiplexer is placed 
in the high impedance state, and the Refresh Address Counter PAL is enabled to output the 
address of the next row to be refreshed. Then the DRAM State PAL activates both RASO# 
and RAS1# to refresh the selected row for both banks at once. After the refresh cycle is 
complete, the Refresh Address Counter PAL increments so that the next refresh cycle 
refreshes the next sequential row. 

The frequency of refreshing and the number of rows to be refreshed depend on the type of 
DRAM. For most larger DRAMs (64KxN and larger), only the lower eight multiplexed 
address bits (A7-A0, 256 rows) must be supplied for the refresh cycle; the upper address 
bits are ignored. The Refresh Address Counter PAL must output only eight bits and only 
the lower eight bits of the address multiplexer must be placed in the high impedance state. 
The OE# signals of the higher order address multiplexers can be tied low. Larger DRAMs 
generally require refresh every 4 milliseconds. The following sections describe refresh specif- 
ically for larger DRAMs, although the concepts apply to smaller DRAMs. 

6.3.5.1 DISTRIBUTED REFRESH 

In distributed refresh, the 256 refresh cycles are distributed equally within the 4-millisecond 
interval. Every 15.625 microseconds (4 milliseconds/256), a single row refresh is performed. 
After 4 miUiseconds all 256 rows have been refreshed, and the pattern repeats. Both the 
3-CLK and 2-CLK designs use distributed refresh. 

The Refresh Interval Counter PAL is programmed to request a single distributed refresh 
cycle at intervals slightly under 15.625 microseconds. The counter requests a new refresh 
cycle after a preset number of CLK cycles. This number is dependent on the CLK frequency 
and can be calculated as follows for a 16-MHz CLK signal: 

16 MHz X 15.625 microseconds - 4/256 = 249.98 

= 249 CLK cycles 



6-25 



iny 



MEMORY INTERFACING 



The term 4/256 is subtracted to allow for the time it takes the DRAM State PAL to respond 
to the request. Refresh requests are always given highest priority; however, if a DRAM 
access is already in progress, it must finish before the refresh cycle can start. The 3-CLK 
controller responds within 1-5 CLKs of the refresh request; the 2-CLK controller responds 
within 1-4 CLKs. The maximum latency (the difference between the longest and shortest 
responses) for either design is therefore 4 CLKs. This time is spread out among all 256 
accesses, so 4/256 is subtracted in the above equations to account for the latency period. 
The counter immediately resets itself after it reaches the maximum count, regardless of this 
latency period. 

Distributed refresh has two advantages over other types of refresh: 

• Refresh cycles are spread out, guaranteeing that the 80386 access is never delayed very 
long for refresh cycles. Most programs execute in approximately the same time, regard- 
less of when they are run with respect to DRAM refreshes. 

• Distributed refresh hardware is typically simpler than hardware required for other types 
of refresh. 

6.3.5.2 BURST REFRESH 

Burst refreshes perform all 256 row refreshes consecutively once every 4 milliseconds rather 
than distributing them equally over the time period. Once a refresh is performed, the next 
4-millisecond period is guaranteed free of refresh cycles. Time-critical sections of code can 
be executed during this time. 

The 3-CLK and 2-CLK designs can be modified for burst refreshes by lengthening the 
maximum count of the Refresh Interval Counter to cover a 4-millisecond interval and holding 
the Refresh Request (RFRQ) signal active for 256 refresh cycles instead of a single refresh 
cycle. The completion of 256 refresh cycles can be determined by clearing the Refresh Address 
Counter PAL before the first refresh cycle and monitoring the outputs until they reach the 
zero address again. The Row Select (ROWSEL) signal can be used to clock the Refresh 
Address Counter PAL. The longer interval counter and extra logic requires another PAL 
device. 

6.3.5.3 DMA REFRESH 

With DMA refresh, the highest priority DMA channel is dedicated to perform refresh cycles 
through DMA rather than through extra logic in the DRAM controller. A periodic timer is 
used to initiate a DMA request; the DMA performs memory accesses to different DRAM 
rows to accomplish refreshes. Either distributed or burst refresh techniques can be used. 

DMA refresh can be used for both 3-CLK and 2-CLK designs. The Refresh Interval Counter 
PAL or another timer periodically initiates a DMA request, and the DMA Controller supplies 
the refresh address. To activate both banks, the DMA Acknowledge(DACK) signal should 
be connected to the RFRQ input of the DRAM State PAL and activated one CLK2 cycle 
before chip selects are sampled by the DRAM State PAL. In this way, the DMA controller 
does not need to activate chip selects. If it does activate the chip selects, the DRAM State 
PAL must be modified to ignore them. This modification prevents the PAL from attempting 
to run a normal access cycle after the refresh cycle is complete. 
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In addition, the DRAM Control PAL must be modified so that the Ready (RDY) signal is 
generated on refresh accesses. Finally, the OE# input of the address multiplexer should be 
tied low so that it never enters the high-impedance state, and the row address should include 
the least-significant address bits (A 1, AO). 

For efficient refreshes, a DMA controller that can perform 32-bit accesses is required. 
Otherwise, consecutive accesses are made to the same row, requiring more refresh cycles 
than necessary for a complete DRAM refresh. 

Unlike the refresh logic for the 3-CLK and 2-CLK designs, DMA accesses often require a 
few clock cycles to acquire and release the 80386 bus. They also require a dedicated 32-bit 
DMA channel. DMA refresh requires only one less PAL device than other refresh methods. 
In most cases, therefore, it is advisable to use dedicated hardware for refresh rather than 
DMA. 



6.3.6 Initialization 

Once the system is initialized, the integrity of the DRAM data and states is maintained, 
even during an 80386 halt or shutdown state or hardware reset, because all DRAM system 
functions are performed in hardware. 

The controller PALs contain some state and counter information that is not implicitly reset 
during a power-up or hardware reset. The state machines are designed so that they enter the 
idle state within 1 8 CLK2 cycles regardless of whether they powerup in a valid state. The 
counters can start in any state. Thus, even though the state machines and counters can 
powerup into any state, they are ready for operation before the 80386 begins its first bus 
access. 

Some DRAMs require a number of warm-up cycles before they can operate. Either method 
listed below can provide these cycles: 

• Performing several dummy DRAM cycles as part of the 80386 initialization process. 
Setting up the 80386 registers and performing a REP LODS instruction is one way to 
perform these dummy cycles. 

• Activating the RFRQ signal, using external logic, for a preset amount of time, causing 
the DRAM control hardware to run several refresh cycles. 

6.3.7 Timing Analysis 

The DRAM design (2-CLK or 3-CLK) for six combinations of DRAM speed and CLK 
frequency is listed in the Table 6-3. The table also indicates for each DRAM type whether 
data transceivers and/or external registers on the PAL outputs must be used with the design. 

Appendix C of this manual contains a timing analysis of all 2-CLK and 3-CLK circuit 
parameters for all six DRAM types. 
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Table 6-3. Designs for Six DRAM Types 




DRAM 


386 CLK 


PAL 


External 


Data 


Access Time 


Rate 


Circuit 


Registers 


xcvrs 


80 nS 


16 MHz 


2-CLK 


optional 


optional 


100 nS 


16 MHz 


2-CLK 


optional 


no 


120 nS 


12 MHz 


2-CLK 


optional 


optional 


150 ns 


16 MHz 


3-CLK 


optional 


yes 


150 nS 


16 MHz 


3-CLK 


yes 


yes 


200 nS 


12 MHz 


3-CLK 


optional 


yes 
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CHAPTER 7 
CACHE SUBSYSTEMS 



Operating at 16 MHz, the 80386 can perform a complete bus cycle in only 125 nanoseconds, 
for a maximum bandwidth of 32 megabytes per second. To sustain this maximum speed, the 
80386 must be matched with a high-performance memory system. The system must be fast 
enough to complete bus cycles with no wait states and large enough to allow the 80386 to 
execute large application programs. 

Traditional memory systems have been implemented with dynamic RAMs (DRAMs), which 
provide a large amount of memory for a small amount of board space and money. However, 
no common low-cost DRAMs are available that can complete every bus cycle in 
125 nanoseconds. Faster static RAMs (SRAMs) can meet the bus timing requirement, but 
they offer a relatively small amount of memory at a higher cost. Large SRAM systems can 
be prohibitively expensive. 

A cache memory system contains a small amount of fast memory (SRAM) and a large 
amount of slow memory (DRAM), The system is configured to simulate a large amount of 
fast memory. Cache memory therefore provides the performance of SRAMs at a cost 
approaching that of DRAMs. A cache memory system (see Figure?- 1) consists of the 
following sections: 

• Cache — fast SRAMs between the processor and the (slower) main memory 

• Main memory — DRAMs 

• Cache controller — logic to implement the cache 
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Figure 7-1. Cache Memory System 
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7.1 INTRODUCTION TO CACHES 

In a cache memory system, all the data is stored in main memory and some data is dupli- 
cated in the cache. When the processor accesses memory, it checks the cache first. If the 
desired data is in the cache, the processor can access it quickly, because the cache is a fast 
memory. If the data is not in the cache, it must be fetched from the main memory. 

A cache reduces average memory access time if it is organized so that the code and data 
that the processor needs most often is in the cache. Programs execute most quickly when 
most operations are transfers to and from the faster cache memory. If the requested data is 
found in the cache, the memory access is called a cache hit; if not, it is called a cache miss. 
The hit rate is the percentage of accesses that are hits; it is affected by the size and physical 
organization of the cache, the cache algorithm, and the program being run. The success of 
a cache system depends on its ability to maintain the data in the cache in a way that increases 
the hit rate. The various cache organizations presented in Section 7.2 reflect different strat- 
egies for achieving this goal. 

7.1.1 Program Locality 

Predicting the location of the next memory access would be impossible if programs accessed 
memory completely at random. However, programs usually access memory in the neighbor- 
hood of locations accessed recently. This principle is known as program locality or locality 
of reference. 

Program locality makes cache systems possible. The same concept, on a larger scale, allows 
demand paging systems to work well. In typical programs, code execution usually proceeds 
sequentially or in small loops so that the next few accesses are nearby. Data variables are 
often accessed several times in succession. Stacks grow and shrink from one end so that the 
next few accesses are all near the top of the stack. Character strings and vectors are often 
scanned sequentially. 

The principle of program locality pertains to how programs tend to behave, but it is not a 
law that all programs always obey. Jumps in code sequences and context switching between 
programs are examples of behavior that may not uphold program locality. 

7.1.2 Block Fetch 

The block fetch uses program locality to increase the hit rate of a cache. The cache control- 
ler partitions the main memory into blocks. Typical block sizes (also known as line size) are 
2, 4, 8, or 16 bytes. A 32-bit processor usually uses two or four words per block. When a 
needed word is not in the cache, the cache controller moves not only the needed word from 
the main memory into the cache, but also the entire block that contains the needed word. 

A block fetch can retrieve the data located before the requested byte (lookbehind), follows 
the requested byte (lookahead), or both. Generally, blocks are aligned (2-byte blocks on 
doubleword boundaries, 4-word blocks on doubleword boundaries). An access to any byte in 
the block copies the whole block into the cache. When memory locations are accessed in 
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ascending order (code accesses, for example), an access to the first byte of a block in main 
memory results in a lookahead block fetch. When memory locations are accessed in descend- 
ing order, the block fetch is look-behind. 

Block size is one of the most important parameters in the design of a cache memory system. 
If the block size is too small, the lookahead and look-behind are reduced, and therefore the 
hit rate is reduced, particularly for programs that do not contain many loops. However, too 
large a block size has the following disadvantages: 

• Larger blocks reduce the number of blocks that fit into a cache. Because each block fetch 
overwrites older cache contents, a small number of blocks results in data being overwrit- 
ten shortly after it is fetched. 

• As a block becomes larger, each additional word is further from the requested word, 
therefore less likely to be needed by the processor (according to program locality). 

• Large blocks tend to require a wider bus between the cache and the main memory, as 
well as more static and dynamic memory, resulting in increased cost. 

As with all cache parameters, the block size must be determined by weighing performance 
(as estimated from simulation) against cost. 



7.2 CACHE ORGANIZATIONS 



7.2.1 Fully Associative Cache 

Most programs make reference to code segments, subroutines, stacks, lists, and buffers located 
in different parts of the address space. An effective cache must therefore hold several 
noncontiguous blocks of data. 

Ideally, a 128-block cache would hold the 128 blocks most likely to be used by the processor 
regardless of the distance between these words in main memory. In such a cache, there 
would be no single relationship between all the addresses of these 128 blocks, so the cache 
would have to store the entire address of each block as well as the block itself. When the 
processor requested data from memory, the cache controller would compare the address of 
the requested data with each of the 128 addresses in the cache. If a match were found, the 
data for that address would be sent to the processor. This type of cache organization, depicted 
in Figure 7-2, is called fully associative. 

A fully associative cache provides the maximum flexibility in determining which blocks are 
stored in the cache at any time. In the previous example, up to 128 unrelated blocks could 
be stored in the cache. Unfortunately, a 128-address compare is usually unacceptably slow, 
expensive, or both. One of the basic issues of cache organization is how to minimize the 
restrictions on which words may be stored in the cache while limiting the number of required 
address comparisons. 
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Figure 7-2. Fully Associative Cache Organization 

7.2.2 Direct Mapped Cache 

In a direct mapped cache, unlike a fully associative cache, only one address comparison is 
needed to determine whether requested data is in the cache. 

The many address comparisons of the fully associative cache are necessary because any 
block from the main memory can be placed in any location of the cache. Thus, every block 
of the cache must be checked for the requested address. The direct mapped cache reduces 
the number of comparisons needed by allowing each block from the main memory only one 
possible location in the cache. 

Each direct mapped cache address has two parts. The first part, called the cache index field, 
contains enough bits to specify a block location within the cache. The second part, called 
the tag field, contains enough bits to distinguish a block from other blocks that may be 
stored at a particular cache location. 
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For example, consider a 64-kilobyte direct mapped cache that contains 16K 32-bit locations 
and caches 16 megabytes of main memory. The cache index field must include 14 bits to 
select one of the 16K blocks in the cache, plus 2 bits (or 4 byte Enables) to select a byte 
from the 4-byte block. The tag field must be 8 bits wide to identify one of the 256 blocks 
that can occupy the selected cache location. The remaining 8 bits of the 32-bit 80386 address 
are decoded to select the cache subsystem from among other memories in the memory space. 
The direct-mapped cache organization is shown in Figure 7-3. 
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Figure 7-3. Direct Mapped Cache Organization 



7-5 



iny 



CACHE SUBSYSTEMS 



In a system such as shown in Figure 7-3, a request for the data at the address 12FFE9H in 
the main memory is handled as follows: 

1. The cache controller determines the cache location from the 14 most significant bits of 
the index field (FFE8H). 

2. The controller compares the tag field (12H) with the tag stored at location FFE8H in 
the cache. 

3. If the tag matches, the processor reads the least significant byte from the data in the 
cache. 

4. If the tag does not match, the controller fetches the 4-byte block at address 12FFE8H in 
the main memory and loads it into location FFE8H of the cache, replacing the current 
block. The controller must also change the tag stored at location FFE8H to 12H. The 
processor then reads the least significant byte from the new block. 

Any address whose index field is FFE8H can be loaded into the cache only at location 
FFE8H; therefore, the cache controller makes only one comparison to determine if the 
requested word is in the cache. Note that the address comparison requires only the tag field 
of the address. The index field need not be compared because anything stored in cache 
location FFE8H has an index field of FFE8H. The direct mapped cache uses direct address- 
ing to eliminate all but one comparison operation. 

The direct mapped cache, however, is not without drawbacks. If the processor in the example 
above makes frequent requests for locations 12FFE8H and 44FFE8H, the controller must 
access the main memory frequently, because only one of these locations can be in the cache 
at a time. Fortunately, this sort of program behavior is infrequent enough that the direct 
mapped cache, although offering poorer performance than a fully associative cache, still 
provides an acceptable performance at a much lower cost. 



7.2.3 Set Associative Cache 

The set associative cache compromises between the extremes of fully associative and direct 
mapped caches. This type of cache has several sets (or groups) of direct mapped blocks that 
operate as several direct mapped caches in parallel. For each cache index, there are several 
block locations allowed, one in each set. A block of data arriving from the main memory 
can go into a particular block location of any set. Figure 7-4 shows the organization for a 
2-way set associative cache. 

With the same amount of memory as the direct mapped cache of the previous example, the 
set associative cache contains half as many locations, but allows two blocks for each location. 
The index field is thus reduced to 1 5 bits, and the extra bit becomes part of the tag field. 

Because the set associative cache has several places for blocks with the same cache index in 
their addresses, the excessive main memory traffic that is a drawback of a direct mapped 
cache is reduced and the hit rate increased. A set associative cache, therefore, performs more 
efficiently than a direct mapped cache. 
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Figure 7-4. Two-Way Set Associative Cache Organization 



The set associative cache, however, is more complex than the direct mapped cache. In the 
2-way set associative cache, there are two locations in the cache in which each block can be 
stored; therefore, the controller must make two comparisons to determine in which block, if 
any, the requested data is located. A set associative cache also requires a wider tag field, 
and thus a larger SRAM to store the tags, than a direct mapped cache with the same amount 
of cache memory and main memory. In addition, when information is placed into the cache, 
a decision must be made as to which block should receive the information. 
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The controller must also decide which block of the cache to overwrite when a block fetch is 
executed. There are several locations, rather than just one, in which the data from the main 
memory could be written. Three common approaches for choosing the block to overwrite are 
as follows: 

• Overwriting the least recently accessed block. This approach requires the controller to 
maintain least-recently used (LRU) bits that indicate the block to overwrite. These bits 
must be updated by the cache controller on each cache transaction. 

• Overwriting the blocks in sequential order. 

• Overwriting a block chosen at random. 

The performance of each strategy depends upon program behavior. Any of the three strate- 
gies is adequate for most set associative cache designs. 



7.3 CACHE UPDATING 

In a cache system, two copies of the same data can exist at once, one in the cache and one 
in the main memory. If one copy is altered and the other is not, two different sets of data 
become associated with the same address. A cache must contain an updating system to prevent 
old data values (called stale data) from being used. Otherwise, the situation shown in 
Figure 7-5 could occur. The following sections describe the write-through and write-back 
methods of updating the main memory during a write operation to the cache. 



7.3.1 Write-Through System 

In a write-through system, the controller copies write data to the main memory immediately 
after it is written to the cache. The result is that the main memory always contains valid 
data. Any block in the cache can be overwritten immediately without data loss. 

The write-through approach is simple, but performance is decreased due to the time required 
to write the data to main memory and increased bus traffic (which is significant in multi- 
processing systems). 



7.3.2 Buffered Write-Through System 

Buffered write-through is a variation of the write-through technique. In a buffered write- 
through system, write accesses to the main memory are buffered, so that the processor can 
begin a new cycle before the write cycle to the main memory is completed. If a write access 
is followed by a read access that is a cache hit, the read access can be performed while the 
main memory is being updated. The decrease in performance of the write-through system is 
thus avoided. However, because usually only a single write access can be buffered, two 
consecutive writes to the main memory will require the processor to wait. A write followed 
by a read miss will also require the processor to wait. 



7-8 



iny 



CACHE SUBSYSTEMS 



PROCESSOR READ DATA; DATA NOT 
FOUND IN CACHE. DATA IS COPIED 
INTO CACHE FROM MEMORY. 



PROCESSOR WRITES A NEW VALUE 
FOR THE DATA JUST READ. 



3. LATER, ANOTHER READ CAUSES 
NEW DATA TO BE OVERWRITTEN. 
NEW DATA IS LOST. 



4. PROCESSOR READS THE SAME 
LOCATION AS IN STEP 1. STALE 
DATA IS COPIED INTO CACHE. 
PROCESSOR GETS WRONG DATA. 



80386 




CACHE 




MEMORY 






W/Ma 




W//M 























80386 




























^^^^ 




iiiiiii 







80386 
















W//M, 




^^^^ 










liiilli 













G30107 



Figure 7-5. Stale Data Problem 

7.3.3 Write-Back System 

In a write-back system, the tag field of each block in the cache includes a bit called the 
altered bit. This bit is set if the block has been written with new data and therefore contains 
data that is more recent than the corresponding data in the main memory. Before overwrit- 
ing any block in the cache, the cache controller checks the altered bit. If it is set, the control- 
ler writes the block to main memory before loading new data into the cache. 

Write-back is faster than write-through because the number of times an altered block must 
be copied into the main memory is usually less than the number of write accesses. However, 
write-back has these disadvantages: 

• Write-back cache controller logic is more complex than write-through. When a write- 
back system must write an altered block to memory, it must reconstruct the write address 
from the tag and perform the write-back cycle as well as the requested access. 

• All altered blocks must be written to the main memory before another device can access 
these blocks in main memory. 
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In a power failure, the data in the cache is lost, so there is no way to tell which locations 
of the main memory contain stale data. Therefore, the main memory as well as the cache 
must be considered volatile and provisions must be made to save the data in the cache in 
the case of a power failure. 



7.3.4 Cache Coherency 

Write-through and write-back eliminate stale data in the main memory caused by cache 
write operations. However, if caches are used in a system in which more than one device has 
access to the main memory (multi-processing systems or DMA systems, for example), another 
stale data problem is introduced. If new data is written to main memory by one device, the 
cache maintained by another device will contain stale data. A system that prevents the stale 
cache data problem is said to maintain cache coherency. Three cache coherency approaches 
are described below: 

• Hardware transparency — Hardware guarantees cache coherency by ensuring that all 
accesses to memory mapped by a cache are seen by the cache. This is accomplished either 
by routing the accesses of all devices to the main memory through the same cache or by 
copying all cache writes both to the main memory and to all other caches that share the 
same memory (a technique known as broadcasting). Hardware transparent systems are 
illustrated in Figure 7-6. 

• Non-cacheable memory — Cache coherency is maintained by designating shared memory 
as non-cacheable. In such a system, all accesses to shared memory are cache misses, 
because the shared memory is never copied into the cache. The non-cacheable memory 
can be identified using chip-select logic or high-address bits. Figure 7-7 illustrates non- 
cacheable memory. 
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Figure 7-6. Hardware Transparency 
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Figure 7-7. Non-Cacheable Memory 

Software can offset the reduction in the hit rate caused by non-cacheable memory by 
using the string move instruction (REP MOVS) to copy data between non-cacheable 
memory and cacheable memory and by mapping shared memory accesses to the cachea- 
ble locations. This technique is especially appropriate for systems in which copying is 
necessary for other reasons (as in some implementations of UNIX for example). 

• Cache flushing — A cache flush writes any altered data to the main memory (if this has 
not been done with write-through) and clears the contents of the cache. If all the caches 
in the system are flushed before a device writes to shared memory, the potential for stale 
data in any cache is eliminated. 

An advantage of cache flushing is that is uses simpler hardware than the other two 
approaches. A disadvantage of this approach is that the memory accesses that follow the 
cache flush will be misses until the cache is refilled with new data. If flushes can be minimized, 
however, this disadvantage may be minor compared to the advantages of cache flushing. 

Combinations of various cache coherency techniques may offer the optimal solution for a 
particular system. For example, a system might use hardware transparency for time-critical 
I/O operations such as paging and non-cacheable memory for slower I/O such as printing. 



7.4 SYSTEM STRUCTURE AND PERFORMANCE 



Performance data for various cache organizations is shown in Table 7-1. This data should 
be weighed against other considerations, such as hardware complexity, in selecting a cache 
organization. 
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Table 7-1. Cache System Performance 



Cache Configuration 


Cache Performance 


Size 


Associativity 


Line Size 


Hit Rate 


Performance Ratio 
Over Non-Cached DRAI^fl 


1K 

8K 

16K 

32K 

32K 

32K 

64K 

64K 

64K 

64K 

64K 

128K 

128K 

128K 


direct 
direct 
direct 
direct 
2-way 
direct 
direct 
2-way 
4-way 
direct 
2-way 
direct 
2-way 
direct 


4 bytes 
4 bytes 
4 bytes 
4 bytes 
4 bytes 
8 bytes 
4 bytes 
4 bytes 
4 bytes 
8 bytes 
8 bytes 
4 bytes 
4 bytes 
8 bytes 


41% 
73% 
81% 
86% 
87% 
91% 
88% 
89% 
89% 
92% 
93% 
89% 
89% 
93% 


0.91 
1.25 
1.35 
1.38 
1.39 
1.41 
1.39 
1.40 
1.40 
1.42 
1.42 
1.39 
1.40 
1.42 


no cache-2 CLK SRAM access 
no cache-4 CLK pipiined DRAIVI 


(100%) 


1.47 
1.00 



7.5 DMA THROUGH CACHE 

Cache coherency is especially relevant to the placement of a DMA controller in a 80386 
system. Because the DMA controller has access to the main memory, it can introduce stale 
data problems. Stale data can be avoided in the following ways: 

• Implementing a transparent cache; that is, directing memory accesses from both the 80386 
and the DMA controller through the cache. 

• Allowing the DMA controller direct access to memory while guaranteeing cache coher- 
ency through non-cacheable memory or cache flushing (see the previous section for expla- 
nations of these techniques). 

The first method is more desirable than the second because it does not require extra hardware 
to guarantee cache coherency. However, with this method, the 80386 and the DMA control- 
ler must contend for memory access. With the second method, the 80386 can access the 
cache while the DMA controller is accessing the memory; as long as the 80386 access is a 
cache hit, the DMA controller does not interfere with the performance of the 80386. Each 
method has advantages. Deciding which method is more suitable depends on the perform- 
ance of the DMA controller. 

In general, if a DMA controller's activity is significantly more time-consuming than that of 
the 80386, it is better to allow the controller direct access to memory. DMA accesses through 
the cache would cause significant delays for the 80386. A 16-bit, 8-MHz Advanced DMA 
(ADMA) controller requires eight CLK2 cycles to write a 32-bit doubleword into memory, 
plus five CLK2 cycles to gain and release control of the bus (using the HOLD signal). In 



7-12 



iny 



CACHE SUBSYSTEMS 



contrast, an 80386 could ensure cache coherency by transferring data between cacheable 
and non-cacheable memory at four CLK2 cycles for each doubleword (no wait states) using 
the REP MOVS instruction. 



7.6 CACHE EXAMPLE 

The cache system example described in this section illustrates some of the decisions a cache 
designer must make. The requirements of a particular system may result in different choices 
than the ones made here. However, the issues presented in this example are likely to arise in 
the process of designing any cache system. 



7.6.1 Example Design 

The cache system uses a direct mapped cache. In previous generations of computers, it was 
often practical to use a 2-way or 4-way associative cache. SRAMs had low memory capac- 
ity, so many of them were needed to construct a reasonable cache. By comparison, the cost 
of comparators and control logic for implementing the associativity (in terms of both dollars 
and board space) was negligible. Today, however, SRAMs hold more memory, cost less, and 
take up less space. It is now more economical to increase cache effectiveness by increasing 
cache size (SRAMs) rather than associativity (jontrol logic and comparators). 

The main memory is updated using write- through. Buffered write-through and write-back 
systems require more logic and are usually cost-effective only if the DRAM response is 
relatively slow (as with a dual-port DRAM shared with other processors or a DMA 
controller). 

The block size is four bytes, which is most convenient for the 32-bit data bus of the 80386. 
An 8-byte block size would transfer twice as much data for every DRAM access, but would 
require a wider bus and more SRAMs and DRAMs. In most cases, the extra cost outweighs 
the extra performance. 

The cache in this example accesses both code and data, rather than only code. Code-only 
caches are easier to implement because there are no write accesses. They can be useful if 
data accesses are infrequent and widely spaced in memory. In general, however, most 
programs make frequent data accesses. The code prefetch function of the 80386 makes the 
access time for code not critical to overall performance, so the performance gain of a code- 
only cache is unimportant. 



7.6.2 Example Cache Memory Organization 

The example cache is organized as shown in Figure 7-8. The cache holds 64 kilobytes 
(16K locations of 4-byte blocks) of data and code and requires 16K 8-bit tag locations. The 
main memory holds 16 megabytes (4M locations of 4-byte blocks). 
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Figure 7-8. Example of Cache Memory Organization 



The 32-bit address from the 80386 is divided into the following three fields: 



• Select — Bits A31-A24 are decoded by chip-select logic to select the cache memory 
subsystem. 

• Tag — Bits A23-A16 identify one of the 256 64-kilobyte sections in the main memory 
(DRAM). 

• Index — Bits A15-A2 identify one of the 16K doubleword locations in the cache. 
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Each doubleword location of the cache can be occupied by one of 256 blocks from the main 
memory (one block from each 64-kilobyte section). 

The 80386 bits A23-A2 are interpreted as follows: 

1. Index bits A15-A2 select the cache location. 

2. Tag bits A23-A16 are matched with the 8 bits of the tag for that location to determine if 
the block in the cache is the block needed by the 80386. 

a. If the tag matches, the 80386 either reads the data in the cache or writes new data to 
the location. In the case of a write, the data is also written to the main memory. 

b. If the tag does not match, a data transfer to or from the main memory is performed. 
Bits A23-A16 (the tag) select one of the 256 64-kilobyte sections of the DRAM, and 
bits A15-A2 select one 4-byte block from that section to transfer to the cache and to 
the processor. The 80386 Byte Enable signals select the requested bytes from the block. 
The new tag for the cache location is written to the tag SRAM. 

7.6.3 Example Cache Implementation 

Figure 7-9 shows the logic for implementing the example cache. The index field (A15-A2) 
is latched early in the cycle to select the tag from the tag RAM. The tag field (A23-A16) is 
latched later in the cycle and compared with the tag from the RAM in the 74F521 compar- 
ator. The output of the comparator is sent to the cache controller to enable either the cache 
or the DRAM for the bus cycle. 

In the case of a hit, the controller enables the cache for the bus cycle. If the access is a write, 
the controller then enables the DRAM for the write-through cycle. In the case of a miss, the 
controller enables the DRAM to update the cache before the access is performed. 
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Figure 7-9. Cache Memory System Implementation 
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The 80386 supports 8-bit, 16-bit, and 32-bit I/O devices that can be mapped into either the 
64-kilobyte I/O address space or the 4-gigabyte physical memory address space. This chapter 
presents the issues to consider when designing an interface to an I/O device. Mapping as 
well as timing considerations are described. Several examples illustrate the design concepts. 



8.1 I/O MAPPING VERSUS MEMORY MAPPING 

I/O mapping and memory mapping of I/O devices differ in the following respects: 

• The address decoding required to generate chip selects for I/O-mapped devices is often 
simpler than that required for memory-mapped devices. I/O-mapped devices reside in the 
I/O space of the 80386 (64 kilobytes); memory-mapped devices reside in a much larger 
memory space (4 gigabytes) that makes use of more address lines. 

• Memory-mapped devices can be accessed using any 80386 instruction, so I/O-to-memory, 
memory-to-I/O, and I/O-to-I/O transfers as well as compare and test operations can be 
coded efficiently. I/O-mapped devices can be accessed only through the IN, OUT, INS, 
and OUTS instructions. All I/O transfers are performed via the AL (8-bit), AX (16-bit), 
or EAX (32-bit) registers. The first 256 bytes of the I/O space are directly addressable. 
The entire 64-kilobyte I/O space is indirectly addressable through the DX register. 

• Memory mapping offers more flexibility in protection than I/O mapping does. Memory- 
mapped devices are protected by memory management and protection features. A device 
can be inaccessible to a task, visible but protected, or fully accessible, depending on where 
the device is mapped in the memory space. Paging provides the same protection levels for 
individual 4-kilobyte pages and indicates whether a page has been written to. The I/O 
privilege level of the 80386 protects I/O-mapped devices by either preventing a task from 
accessing any I/O devices or by allowing a task to access all I/O devices. A virtual-8086- 
mode I/O permission bitmap can be used to select the privilege level for a combination 
of I/O bytes. 

8.2 8-BIT, 16-BIT, AND 32-BIT I/O INTERFACES 

The 80386 can operate with 8-bit, 16-bit, and 32-bit peripherals. The interface to a periph- 
eral device depends not only upon data width, but also upon the signal requirements of the 
device and its location within the memory space or I/O space. 

8.2.1 Address Decoding 

Address decoding to generate chip selects must be performed whether I/O devices are 
I/O-mapped or memory-mapped. The decoding technique should be simple to minimize the 
amount of decoding logic. 
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One possible technique for decoding memory-mapped I/O addresses is to map the entire 
I/O space of the 80386 into a 64-kilobyte region of the memory space. The address decoding 
logic can be configured so that each I/O device responds to both a memory address and an 
I/O address. Such a configuration is compatible for both software that uses I/O instructions 
and software that assumes memory-mapped I/O. 

Address decoding can be simplified by spacing the addresses of I/O devices so that some of 
the lower address lines can be omitted. For example, if devices are placed at every fourth 
address, the 80386 Byte Enable outputs (BE3#-BE0#) can be ignored for I/O accesses and 
each device can be connected directly to the same eight data lines. The 64-kilobyte I/O 
space is large enough to allow the necessary freedom in allocating addresses for individual 
devices. 

Addresses can be assigned to I/O devices arbitrarily within the I/O space or memory space. 
Addresses for either I/O-mapped or memory-mapped devices should be selected to minimize 
the number of address lines needed. 



8.2.2 8-Bit I/O 

Eight-bit I/O devices can be connected to any of the four 8-bit sections of the data bus. 
Table 8-1 illustrates how the address assigned to a device determines which section of the 
data bus is used to transfer data to and from the device. 

In a write cycle, if BE3# and/or BE2# is active but not BE1# or BE0#, the write data on 
the top half of the data bus is duplicated on the bottom half. If the addresses of two devices 
differ only in the values of BE3#-BE0# (the addresses lie within the same doubleword 
boundaries), BE3#-BE0# must be decoded to provide a chip select signal that prevents a 
write to one device from erroneously performing a write to the other. This chip select can be 
generated using an address decoder PAL device or TTL logic. 

Another technique for interfacing with 8-bit peripherals is shown in Figure 8-1. The 32-bit 
data bus is multiplexed onto an 8 -bit bus to accommodate byte-oriented DMA or block 
transfers to memory-mapped 8-bit I/O devices. The addresses assigned to devices connected 
to this interface can be closely spaced because only one 8-bit section of the data bus is 
enabled at a time. 



Table 8-1. Data Lines for 8-Bit I/O Addresses 



Address 


4N + 3 


4N + 2 


4N + 1 


4N 


Byte 


D31-D24 


D23-D16 


D15-D8 


D7-D0 


Word 


D31-D16 


D15-D0 


Doubleword 


D31-D0 
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Figure 8-1. 32-Bit to 8-Bit Bus Conversion 
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8.2.3 16-Bit I/O 

To avoid extra bus cycles and to simplify device selection, 16-bit I/O devices should be 
assigned to even addresses. If I/O addresses are located on adjacent word boundaries, address 
decoding must generate the Bus Size 16 (BS16#) signal so that the 80386 performs a 16-bit 
bus cycle. If the addresses are located on every other word boundary (every doubleword 
address), BS16# is not needed. 



8.2.4 32-Bit I/O 

To avoid extra bus cycles and to simplify device selection, 32-bit devices should be assigned 
to addresses that are even multiples of four. Chip select for a 32-bit device should be condi- 
tioned by all byte enables (BE3#-BE0#) being active. 



8.2.5 Linear Chip Selects 

Systems with 14 or fewer I/O ports that reside only in the I/O space or that require more 
than one active select (at least one high active and one low active) can use linear chip selects 
to access I/O devices. Latched address lines A2-A15 connect directly to I/O device selects 
as shown in Figure 8-2. 



8.3 BASICI/0 INTERFACE 

In a typical 80386 system design, a number of slave I/O devices can be controlled through 
the same local bus interface. Other I/O devices, particularly those capable of controlling the 
local bus, require more complex interfaces. This section presents a basic interface for slave 
peripherals. 

The high performance and flexibility of the 80386 local bus interface plus the increased 
availability of programmable and semi-custom logic make it feasible to design custom bus 
control logic that meets the requirements of particular system. 

The basic I/O interface shown in Figure 8-3 can be used to connect the 80386 to virtually 
all slave peripherals. The following list includes some common peripherals compatible with 
this interface: 

8259A Programmable Interrupt Controller 

8237 DMA Controller (remote mode) 

82258 Advanced DMA Controller (remote mode) 

8253, 8254 Programmable Interval Timer 

8272 Floppy Disk Controller 

82062, 82064 Fixed Disk Controller 

8274 Multi-Protocol Serial Controller 

8255 Programmable Peripheral Interface 

8041, 8042 Universal Peripheral Interface 
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Figure 8-2. Linear Chip Selects 



The bus interface control logic presented here is identical to the one used in the basic memory 
interface described in Chapter 6. In most systems, the same control logic, address latches, 
and data buffers can be used to access both memory and I/O devices. The schematic of the 
interface is shown in Figure 8-4 and described in the following sections. 



8.3.1 Address Latch 

Latches maintain the address for the duration of the bus cycle. In this example, 74x373 
latches are used. 

The 74x373 Latch Enable (LE) input is controlled by the Address Latch Enable (ALE) 
signal from the bus control logic that goes active at the start of each bus cycle. The 74x373 
Output Enable (0E#) is always active. 
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Figure 8-3. Basic I/O Interface Block Diagram 

8.3.2 Address Decoder 

In this example, the address decoder, which converts the 80386 address into chip-select 
signals, is located before the address latches. In general, the decoder may also be placed 
after the latches. If it is placed before the latches, the chip-select signal becomes valid as 
early as possible but must be latched along with the address. Therefore, the number of address 
latches needed is determined by the location of the address decoder as well as the number 
of address bits and chip-select signals required by the interface. The chip-select signals are 
routed to the bus control logic to set the correct number of wait states for the accessed 
device. 

The decoder consists of two one-of-four decoders, one for memory address decoding and one 
for I/O address decoding. In general, the number of decoders needed depends on the memory 
mapping complexity. In this basic example, an output of the memory address decoder 
activates the I/O address decoder for I/O accesses. The addresses for the I/O devices are 
located so that only address bits A4 and A5 are needed to generate the correct chip-select 
signal. 
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8.3.3 Data Transceiver 

Standard 8-bit transceivers (74x245, in this example) provide isolation and additional drive 
capability for the 80386 data bus. Transceivers are necessary to prevent the contention on 
the data bus that occurs if some devices are slow to remove read data from the data bus 
after a read cycle. If a write cycle follows a read cycle, the 80386 may drive the data bus 
before a slow device has removed its outputs from the bus, potentially causing bus contention 
problems. Transceivers can be omitted only if the data float time of the device is short enough 
and the load on the 80386 data pins meets device specifications. 

A bus interface must include enough transceivers to accommodate the device with the most 
inputs and outputs on the data bus. If the widest device has 16 data bits and if the I/O 
addresses are located so that all devices are connected only to the lower half of the data bus, 
only two 8-bit transceivers are needed. 

The 74x245 transceiver is controlled through two input signals: 

• Data Transmit /Receive (DT/R#) — When high, this input enables the transceiver for a 
write cycle. When low, it enables the transceiver for a read cycle. This signal is just a 
latched version of the 80386 W/R# output. 

• Data Enable (DEN#) — When low, this input enables the transceiver outputs. This signal 
is generated by the bus control logic. 

8.3.4 Bus Control Logic 

The bus control logic for the basic I/O interface is the same as the logic for the memory 
interface described in Section 6.2. The bus controller decodes the 80386 status outputs 
(W/R#, M/IO#, and D/C#) and activates a command signal for the type of bus cycle 
requested. The command signal corresponds to the bus cycle types (described in Chapter 3) 
as follows: 

• Memory data read and memory code read cycles generate the Memory Read Command 
(MRDC#) output. MRDC# commands the selected memory device to output data. 

• I/O read cycles generate the I/O Read Command (IORC#) output. IORC# commands 
the selected I/O device to output data. 

• Memory write cycles generate the Memory Write Command (MWTC#) output. MWTC# 
commands the selected memory device to receive the data on the data bus. 

• I/O write cycles generate the I/O Write Command (IOWC#) output. IOWC# commands 
the selected memory device to receive the data on the data bus. 

Interrupt-acknowledge cycles generate the Interrupt Acknowledge (INTA#) output, which 
is returned to the 8259A Interrupt Controller. 

The bus controller also controls the READY# input to the 80386 that ends each bus cycle. 
The PAL-2 bus control PAL counts wait states and returns READY# after the number of 
wait states required by the accessed device. The design of this portion of the bus controller 
depends on the requirements of the system; relatively simple systems need less wait-state 
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logic than more complex systems. The basic interface described here uses a PAL device to 
generate READY#; other designs may use counters and/or shift registers. 

If several I/O devices reside on the local bus, READY# logic can be simplified by combin- 
ing into a single input the chip selects for devices that require the same number of wait 
states. The CSIO# input of PAL-1 generates the same number of wait states for all I/O 
accesses. Adding wait states to some devices to make the wait-state requirements of several 
devices the same does not significantly impact performance. If the response of the device is 
already slow (four wait states, for example), the additional wait state amounts to a relatively 
small delay. Typically, I/O devices are used infrequently enough that the access time is not 
critical. 



8.4 TIMING ANALYSIS FOR I/O OPERATIONS 

In this section, timing requirements for devices that use the basic I/O interface are discussed. 
The values of the various device specifications are examples only; for correct timing analysis, 
always refer to the latest data sheet for the particular device . 

Timing for 80386 I/O cycles is identical to memory cycle timing in most respects; in partic- 
ular, timing depends on the design of the interface. The worst-case timing values are calcu- 
lated by assuming the maximum delay in the address latches, chip select logic, and command 
signals, and the longest propagation delay through the data transceivers (if used). These 
calculations yield the minimum possible access time for an I/O access for comparison with 
the access time of a particular I/O device. Wait states must be added to the basic worst- 
case values until read and write cycle times exceed minimum device access times. 

The timing requirement for the address decoder dictates that the logic be combinational (not 
latched or registered) with a propagation delay less than the maximum delay calculated 
below. 

The CSl WS signal requires a maximum decoder delay of 38.75 nanoseconds: 

(3 X CLK2 period) - 80386 Addr Valid - PAL setup 
(3x31.25) - 40 - 15 

= 38.75 nanoseconds 
(CLK2 = 32 MHz) 

The CSOWS signal must be slightly faster in order to activate NA#: 

(3 X CLK2 period) - 80386 Addr Valid - (2 x OR prop, delay) 

- 80386 NA# setup 

(3x31.25) - 40 - (2x6) 

- 10 

= 31.75 nanoseconds 
(CLK2 = 32 MHz) 
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The timings of the other signals can be calculated from the waveforms in Figure 8-5. In the 
following example, the timings for I/O accesses are calculated for CLK2 = 32 MHz and 
B-series PALs. All times are in nanoseconds. 

tAR: Address stable before Read (IORC# fall) 
tAW: Address stable before Write (IOWC# fall) 

(5 X CLK2 period) -PAL RegOut Max -Latch Enable Max 

+ PAL RegOut Min 

(5x31.25) - 12 - 11.5 

+ 

= 132.75 nanoseconds 

tRR: Read (IORC#) pulse width 

(9 X CLK2 period) - PAL RegOut Max + PAL RegOut Min 

(9x31.25) - 12 +0 

= 269.25 nanoseconds 

tWW: Write (IOWC#) pulse width 

(10 X CLK2 period) - PAL RegOut Max + PAL RegOut Min 
(10x31.25) - 12 +0 

= 300.5 nanoseconds 

tRA: Address hold after Read (IORC# rise) 

(6 x CLK2 period) - PAL RegOut Max + PAL RegOut Min 

+ Latch Enable Min 

(6x31.25) - 12 +0 

+ 5 

= 180.5 nanoseconds 

tWA: Address hold after Write (IOWC# rise) 

(7 X CLK2 period) - PAL RegOut Max + PAL RegOut Min 

+ Latch Enable Min 

(7x31.25) - 12 +0 

+ 5 

= 211.75 nanoseconds 
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Figure 8-5. Basic I/O Timing Diagram 
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tAD: Data delay from Address 

(12 X CLK2 period) - PAL RegOut Max + Latch Enable Max 

- xcvr. prop Min — 80386 Data Setup Min 
(12x31.25) - 12 ~~ 11.5 

- 6 

- 10 
= 335.5 nanoseconds 

tRD: Data delay from Read (IORC#) 

(9 X CLK2 period) — PAL RegOut Max — xcvr. prop Min 

- 80386 Data Setup Min 

(9x3L25) - 12 - 6 

- 10 

= 253.25 nanoseconds 

tDF: read (IORC# rise) to Data Float 

(8 X CLK2 period) - PAL RegOut Max + PAL RegOut Min 

+ xcvr. Enable Min 

(8x31.25) - 12 +0 

+ 3 

= 241 nanoseconds 

tDW: Data setup before write (IOWC# rise) 

(10 X CLK2 period) - PAL RegOut Max - xcvr. Enable Max 

+ PAL RegOut Min 

(10x31.25) - 12 - 11 

+ 

= 289.5 nanoseconds 

tWD: Data hold after write (IOWC# rise) 

(2 X CLK2 period) - PAL RegOut + PAL RegOut 

+ xcvr. Disable 

(2x31.25) - 12 +0 

+ 2 

= 52.5 nanoseconds 

tRV: command recovery time 

( 1 1 X CLK2 period) - PAL RegOut Max + PAL RegOut Min 
(11x31.25) - 12 +0 

== 331.75 nanoseconds 
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Many peripherals require a minimum recovery time between back-to-back accesses. This 
recovery time is usually provided in software by a series of NOP instructions. A JMP to the 
next instruction also provides a delay because it flushes the 80386 Prefetch Queue; this 
method has a more predictable execution time than the NOP method. 

In 80386 systems, the instructions that provide recovery time are executed more quickly 
than in earlier systems. For software compatibility with earlier microprocessor generations, 
hardware must guarantee the recovery time. However, the circuitry to delay bus commands 
selectively for the specific instance of back-to-back accesses to a particular device is typically 
more complex than the frequency of such accesses justifies. Therefore, the preferred solution 
is to delay all I/O cycles by the minimum recovery time. Because most I/O accesses are 
relatively infrequent, performance is not degraded. 

The I/O access timings of the basic interface are compatible with all of the currently avail- 
able Intel peripherals. (In some cases, the high-speed versions of these peripherals are 
required). Table 8-2 compares several peripheral timings with the timings provided by bus 
controller. 

Only two peripherals do not meet the bus controller specifications: the 8041 and 8042 UPIs 
(Universal Peripheral Interface 8-bit Microcomputers). These intelligent peripherals meet 
all but the command recovery specification, so they can be used if this delay is implemented 
in software. 



8.5 BASIC I/O EXAMPLES 

In this section, two examples of the interface to slave I/O devices are presented. Typically, 
several of these devices exist on the 80386 local bus. The basic I/O interface presented above 
is used for both examples. 





Table 8-2. Timings for Peripherals Using Basic I/O Interface 
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8.5.1 8274 Serial Controller 

The 8274 Multi-Protocol Serial Controller (MPSC) is designed to interface high-speed serial 
communications lines using a variety of communications protocols, including asynchronous, 
IBM bisynchronous, and HDLC/SDLC protocols. The 8274 contains two independent full- 
duplex channels and can serve as a high-performance replacement for two 8251 A Universal 
Synchronous/Asynchronous Receiver Transmitters (USARTs). 

Figure 8-6 shows connections from the basic I/O interface through which the 80386 
communicates with the 8274. The 8274 is accessed as a sequence of four 8-bit I/O addresses 
(I/O-mapped or memory-mapped). The Serial I/O (SERIO#) signal is a chip select gener- 
ated by address decoding logic. RD# and WR# signals are provided by the bus control logic. 
DB7-DB0 inputs connect to the lower eight outputs of the data transceiver (D7-D0). 

The 8274 Al and AO inputs are used for channel selection and data or command selection. 
These inputs are connected to two address lines that are determined by the 8274 addresses. 
The addresses must be chosen so that the Al and AO inputs receive the correct signals for 
addressing the 8274. 

The 8274 requires a minimum recovery time between back-to-back accesses that is provided 
for in the basic I/O interface hardware. 



8.5.2 8259A Interrupt Controller 

The 8259A Programmable Interrupt Controller is designed for use in interrupt-driven 
microcomputer systems. A single 8259A can process up to eight interrupts. Multiple 8259As 
can be cascaded to accommodate up to 64 interrupts. A technique to handle more than 
64 interrupts is discussed at the end of this section. 
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Figure 8-6. 8274 Interface 
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The 8259 A handles interrupt priority resolution and returns a preprogrammed service routine 
vector to the 80386 during an interrupt-acknowledge cycle. Intel Application Note AP'59 
contains detailed information on configurations of the 8 259 A. 



8.5.2.1 SINGLE INTERRUPT CONTROLLER 

Figure 8-7 shov^^s the connections from the basic I/O interface used for the 80386 and a 
single 8259A. Programmable Interrupt Controller (PIC#) is a chip-select signal from the 
address decoding logic. INTA#, RD#, and WR# are generated by the bus control logic. 
BD7-BD0 are connected to the lower eight outputs of the data transceiver. The A2 bit, 
connected to the 8259A AO input, is used by the 80386 to distinguish between the two inter- 
rupt acknowledge cycles; 8259A register addresses must therefore be located at two consec- 
utive doubleword boundaries. 

When an interrupt occurs, the 8259A activates its Interrupt (INT) output, which is connected 
to the Interrupt Request (INTR) input of the 80386. The 80386 automatically executes two 
back-to-back interrupt-acknowledge cycles, as described in Chapter 3. The 8259A timing 
requirements are as follows: 

• Each interrupt-acknowledge cycle must be extended by at least one wait state. Wait-state 
generator logic must provide for this extension. 

• Four idle bus cycles must be inserted between the two interrupt-acknowledge cycles. The 
80386 automatically inserts these idle cycles. 
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Figure 8-7. Single 8259A Interface 
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8.5.2.2 CASCADED INTERRUPT CONTROLLERS 

Several 8259As can be cascaded to handle up to 64 interrupt requests. In a cascaded config- 
uration, one 8259A is designated as the master controller; it receives input from the other 
8259As, called slave controllers. The interface between the 80386 and multiple cascaded 
8259As is an extension of the single-8259A interface with the following additions: 

• The cascade address outputs (CAS2#-CAS0#) are output to provide address and chip- 
select signals for the slave controllers. 

• The interrupt request lines (IR7-IR0) of the master controller are connected to the INT 
outputs of the slave controllers. 

Each slave controller resolves priority between up to eight interrupt requests and transmits 
a single interrupt request to the master controller. The master controller, in turn, resolves 
interrupt priority between up to eight slave controllers and transmits a single interrupt request 
to the 80386. 

The timing of the interface is basically the same as that of a single 8259A. During the first 
interrupt-acknowledge cycle, all the 8259As freeze the states of their interrupt request inputs. 
The master controller outputs the cascade address to select the slave controller that is gener- 
ating the request with the highest priority. During the second interrupt-acknowledge cycle, 
the selected slave controller outputs an interrupt vector to the 80386. 

Chapter 9 describes the interface to slave controllers that reside on a MULTIBUS I system 
bus. 

8.5.2.3 HANDLING MORE THAN 64 INTERRUPTS 

If an 80386 system requires more than 64 interrupt request lines, a third level of 8259As in 
polled mode can be added to the configuration described above. When a third-level control- 
ler receives an interrupt request, it drives one of the interrupt request inputs to a slave 
controller active. The slave controller sends an interrupt request to the master controller, 
and the master controller interrupts the 80386. The slave controller then returns a service- 
routine vector to the 80386. The service routine must include commands to poll the third 
level of interrupt controllers to determine the source of the interrupt request. 

The only additional hardware required to handle more than 64 interrupts are the extra 8259As 
and the chip-select logic. For maximum performance, third-level interrupt controllers should 
be used only for noncritical, infrequently used interrupts. 

8.6 80286-COMPATIBLE BUS CYCLES 

Some devices (the 82258, for example) require an 80286-compatible interface in order to 
communicate with the 80386. An 80286-compatible interface must generate the following 
signals: 

• Address bits Al and AO, and Byte High Enable (BHE#) from the 80386 BE3#-BE0# 
outputs 
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• Bus cycle definition signals S0# and SI # from the 80386 M/IO#, W/R#, and D/C# 
outputs 

• Address Latch Enable (ALE#), Device Enable (DEN), and Data Transmit/Receive 
(DT/R#) signals 

• I/O Read Command (IORC#) and I/O Write Command (IOWC#) signals for I/O cycles 

• Memory Read Command (MRDC#) and Memory Write Command (MWTC#) signals 
for memory cycles 

• Interrupt Acknowledge (INTA#) signal for interrupt-acknowledge cycles 

In the following example, the interface is constructed using the 80286-compatible bus 
controller (82288) and bus arbiter (82289). The 82289, along with the bus arbiters of other 
processing subsystems, coordinates control of the bus between the 80386 and other bus 
masters. The 82288 provides the control signals to perform bus cycles. Communication 
between the 80386 and these devices is accomplished through PALs that are programmed 
to perform all necessary signal translation and generation. Latching and buffering of the 
data and address buses is performed by TTL logic. 

Figure 8-8 shows a block diagram of the interface, which consists of the following parts: 

AO/Al generator — ^Generates the lower address bits from 80386 BE0#-BE3# outputs 

Address decoder — Determines the device the 80386 will access 

Address latches — Connect directly to 80386 address pins A19-A2 and the outputs of the 
AO/Al generator 

Data transceivers — Connect directly to 80386 data pins D15-D0 

S0#/S1# generator— Translates 80386 outputs into the S0# and Sl# signals 

Wait-state generator — Controls the length of the 80386 bus cycle through the READY# 
signal 

82288 Bus Controller — Generates the bus command signals 

82289 Bus Arbiter — ^Arbitrates contention for bus control between the 80386 and other 
bus masters 

8.6.1 AO/Al Generator 

The AO, Al, and BHE# signals are 80286-compatible. These signals are generated from the 
80386 byte enables (BE0#-BE3#) as shown in Table 8-3. The truth table can be imple- 
mented with the logic shown in Figure 8-9. 

8.6.2 S0#/S1# Generator 

S0# and SI # are 80286-compatible status signals that must be provided for the 82288 and 
82289. The S0#/S1# logic in Figure 8-10 generates these signals from 80386 status outputs 
(D/C#, M/IO#, and W/R#) and wait-state generator outputs. WSl and WS2 are wait- 
state generator outputs that correspond to the first and second wait states of the 80386 bus 
cycle. These signals ensure that S0# and SI # are valid for two CLK cycles. 
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Figure 8-8. 80286-Compatible Interface 

8.6.3 Wait-State Generator 

The wait-state generator PAL shown in Figure 8-11 controls the READY# input of the 
80386. For local bus cycles, the wait-state generator produces signal outputs that correspond 
to each wait state of the 80386 bus cycle, and the PAL READY# output uses these signals 
to set READY# active after the required number of wait states. Two of the wait-state signals, 
WSl and WS2, are also used to generate S0# and Sl#, as described above. 

The PCLK signal, which necessary for producing 80286-compatible wait states, is generated 
by dividing the CLK signal from the 82384 by two. 
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Table 8-3. 


AO, A1 


, and BHE# Truth Table 


80386 Signals 


16-Bit Bus Signals 


Comments 


BE3# 


BE2# 


BE1# 


BEO# 


A1 


BHE# 


BLE# (AO) 


H* 


H* 


H* 


H* 


X 


X 


X 


X— no active bytes 


H 


H 


H 


L 


L 


H 


L 




H 


H 


L 


H 


L 


L 


H 




H 


H 


L 


L 


L 


L 


L 




H 


L 


H 


H 


H 


H 


L 




H* 


L* 


H* 


L* 


X 


X 


X 


X— not contiguous bytes 


H 


L 


L 


H 


L 


L 


H 




H 


L 


L 


L 


L 


L 


L 




L 


H 


H 


H 


H 


L 


H 




L* 


H* 


H* 


L* 


X 


X 


X 


X— not contiguous bytes 


L* 


H* 


L* 


H* 


X 


X 


X 


X— not contiguous bytes 


L* 


H* 


L* 


L* 


X 


X 


X 


X— not contiguous bytes 


L 


L 


H 


H 


H 


L 


L 




L* 


L* 


H* 


L* 


X 


X 


X 


X— not contiguous bytes 


L 


L 


L 


H 


L 


L 


H 




L 


L 


L 


L 


L 


L 


L 




BLE# asserted when D0-D7 of 16-bit bus is active. 




BHE# asserted when D8-D15 of 16-bit bus is active. 




A1 low for all even words; A1 high for all odd words. 




Key: 




X = don't care 




H = high voltage level 




L = low voltage level 




* = a non-occurring pattern of Byte Enables; either none are asserted, or the pattern has Byte Enables | 


asserted for non-contiguous bytes 





To meet the READY# input hold time requirement (25 nanoseconds) for the 82288 Bus 
Controller, the READY# signal must be two CLK cycles long. Therefore, two PAL equations 
are required to generate READY#. The first equation generates the Ready Pulse 
(RDYPLSE) output. RDYPLSE is fed into the READY# equation to extend READY# by 
an additional CLK cycle. These signals are gated by PCLK. 

RDYPLSE : = ARDY * PCLK 

/READY := ARDY* PCLK + RDYPLSE 



8.6.4 Bus Controller and Bus Arbiter 

Connections for the 82288 and 82289 are shown in Figure 8-12. The 82288 MB input is tied 
low so that the 82288 operates in local-bus mode. Both the 82288 and the 82289 are selected 
by an output of the address decoder that selects 80286-compatible cycles. The AEN# signal 
from the 82289 enables the 82288 outputs. 
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Figure 8-9. AO, A1, and BHE# Logic 



8.6.5 82258 ADMA Controller 

The 82258 Advanced Direct Memory Access (ADMA) controller performs DMA transfers 
between main memory and an I/O device, typically a magnetic disk or communications 
channel, without intervention from the 80386. Shifting the I/O processing function from the 
80386 to the 82258 improves overall system performance because the 80386 doesn't have to 
switch context for every transfer. 

The 82258 operates from the CLK output of the 82384 and provides the following advanced 
features that are not available in previous generations of DMA controllers: 

• Command chaining to perform multiple commands sequentially 

• Data chaining to scatter data to separate memory locations and to gather data from 
separate locations (this feature is useful for demand paging) 

• Auto-assembly and disassembly to convert from 16-bit memory to 8-bit I/O or vice versa 
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Figure 8-10. S0#/S1# Generator Logic 
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Figure 8-11. Wait-State Generator Logic 



Compare, translate, and verify functions 

The option to use one of the four high-speed channels as a lower-speed, multiplexed 
channel. The 82258 gains up to 32 more channels through multiplexing 
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Figure 8-12. 82288 and 82289 Connections 

The 82258, paired with the 82288 Bus Controller, is capable of being a bus master on a 
common local bus and/or system bus with the 80386 and its bus controller. The 82258 
requires both a local bus interface to act as bus master and an 80386 interface to commu- 
nicate directly with the 80386. 



8.6.5.1 82258 AS BUS MASTER 



The 82258 operating mode determines the type of bus interface it generates. In the 80286 
mode, the 82258 generates the signals for direct interface with an 80286. In this example, 
the 82258 is set to 80286 mode because the 80386 resembles the 80286 more than the 80186 
or 8086. The 82258 is initialized to 80286 mode by holding its A23 pin high with a puUup 
resistor during reset. 
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The 82258 interface must include logic for sharing control of the local bus with the 80386. 
The HOLD and Hold Acknowledge (HLDA) pins on both the 80386 and the 82258 facili- 
tate the transfer of bus control between the 80386 and the 82258. 

Figure 8-13 shows the logic to transfer bus control. When the 82258 needs bus access, it 
asserts its HOLD request signal, which is synchronized to CLK2 to meet the synchronous 
setup and hold times of the 80386. The resulting Processor Hold (PHOLD) signal sets the 
80386 HOLD input active. 

When the 80386 recognizes the HOLD request, it completes the current bus cycle, then 
places all its outputs except HLDA in the high impedance state and asserts HLDA. External 
logic must use HLDA to disable the output buffers of the 80386 bus controller, data bus, 
and address bus, and enable the output buffers of the 82258 and its bus controller, data bus, 
and address bus. 

The wait-state generator must be started with the ALE output of the 82288 Bus Controller. 
Although the 82258 can share wait-state generator logic with the 80386, the logic must be 
modified to support longer wait states for 82258 cycles. The 82258 divides its CLK input by 
two internally, so that its wait state requires two CLK cycles rather than one. In addition, 
the READY# output must meet the 82258 input hold time requirement of 25 nanoseconds. 
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Figure 8-13. HOLD and HLDA Logic for 80386-82258 Interface 
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When the 82258 completes its operation, its HOLD request goes inactive (low), disabling 
the 82258 output buffers and re-enabling the 80386 and its output buffer. 

8.6.5.2 82258 AS PERIPHERAL 

Although most of the communication between the 80386 and the 82258 is achieved indirectly 
through memory, the 80386 occasionally performs bus cycles to the 82258. For example, the 
80386 performs a direct access to set the general mode register during initialization. The 
access occurs asynchronously over the slave mode interface of the 82258 that is shown in 
Figure 8-14. The interface consists of the following pins: 

• Chip Select (CS#) — enables the slave mode interface 

• Control (RD#, WR#) — indicates bus cycle type (asynchronous interface) 

• Register Address (A7-A0) — selects an 82258 internal register 

• Data (D15-D0)— transfers data to and from the 82258 

With the 82258, asynchronous cycles must be used to allow time for the conversion of 80386 
status signals to 80286-compatible inputs. The S0# and Sl# inputs of the 82258 must there- 
fore be inactive (high) during slave mode operations. Asynchronous cycles require an address 
hold time after a read command or write command, so the address outputs from the 80386 
(A7-A2, and decoded Al, AO, and BHE#) that connect to corresponding inputs of the 82258 
must be latched. Because A7-A0 and BHE# become 82258 outputs after initialization, regis- 
tered transceivers (74F543) serve as these latches. 

ADMA Enable (ADMAEN#) is a chip select generated by address decoding logic during 
80386 accesses to the I/O addresses designated for the 82258. The RD# and WR# command 
signals from the 80386 bus control logic must be delayed to provide the proper setup time 
from chip select to command inputs. This delay can be generated using wait-state generator 
signals. 
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Figure 8-14. 82258 Slave Mode Interface 
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8.6.6 82586 LAN Coprocessor 

The 82586 is an intelligent, high-performance communications controller designed to perform 
most tasks required for controlling access to a local area network (LAN). In most applica- 
tions, the 82586 is the communication manager for a station connected to a LAN. Such a 
station usually includes a host CPU, shared memory, a Serial Interface Unit, a transceiver, 
and a LAN link (see Figure 8-15). The 82586 performs all functions associated with data 
transfer between the shared memory and the LAN link, including: 

• Framing 

• Link management 

• Address filtering 
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Figure 8-15. LAN Station 
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• Error detection 

• Data encoding 

• Network management 

• Direct memory access (DMA) 

• Buffer chaining 

• High-level (user) command interpretation 

The 82586 has two interfaces: a bus interface to the 80386 local bus and a network interface 
to the Serial Interface Unit. The bus interface is described here. For detailed information 
on using the 82586, refer to the Local Area Networking (LAN) Component User's Manual, 

The 82586, which is a master on the 80386 local bus, communicates directly with the 80386 
through the Channel Attention (CA) and interrupt (INT) signals. There are several ways 
to design an interface between the 82586 and the 80386. In general, higher performance 
interfaces (requiring less servicing time from the 80386) are more expensive. Four types of 
interfaces are described in this section: 

• Dedicated CPU 

• Decoupled dual-port memory 

• Coupled dual-port memory 

• Shared bus 

8.6.6.1 DEDICATED CPU 

Dedicating a CPU to control the 82586 results in a high-performance, high-cost interface. 
The CPU, typically an 80186, an 80188, or a microcontroller, executes the data link layer 
(a functional division) of software and sometimes the network, transport, and session layers 
as well. (For definitions of these layers, see the Local Area Networking (LAN) Components 
User's Manual). The dedicated CPU relieves the 80386 of these layers and provides a high- 
level, message-oriented interface that can be treated in software as a standard I/O device. 
In hardware, the interface is mapped into a dual-port memory. 

8.6.6.2 DECOUPLED DUAL-PORT MEMORY 

A decoupled dual-port memory interface, shown in Figure 8-16, contains two sections of 
memory: 

• 80386 core memory — typically DRAM that provides executable memory space for the 
operating system 

• 82586 communication channel memory — typically dual-ported SRAM that contains the 
commands and buffers of the 82586 
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Figure 8-16. Decoupled Dual-Port Memory Interface 

Only the dual-ported SRAM is shared; the 82586 cannot access the 80386 core memory. 
The 80386 and 82586 operate in parallel except when both require access to the SRAM. In 
this instance, one processor must wait while the other completes its access. At all other 
times, the two devices are decoupled. 

This interface requires at least one level of data copying to move data between the 80386 
core memory and the 82586 communication channel memory. However, usually the data 
must be copied to separate the frame header information. 

8.6.6.3 COUPLED DUAL-PORT MEMORY 

In a coupled dual-port memory interface, the 80386 and the 82586 share a common memory 
space as illustrated in Figure 8-17. The 82586, with 24 address bits, can address up to 16 
megabytes of memory. If the 80386 memory is larger than 16 megabytes, some memory is 
inaccessible to the 82586; this memory must be taken into account in the system design. 

The advantage of coupled dual-port memory is that the 82586 can perform DMA transfers 
directly into the operating system memory. In this case, other logic must remove the frame 
header information from the data prior to the DMA transfer. Through the buffer-chaining 
feature of the 82586, the header information can be directed to a separate buffer, as long as 
the minimum buffer size requirements are met. 
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Figure 8-17. Coupled Dual-Port Memory Interface 




Figure 8-18. Shared Bus Interface 



8.6.6.4 Shared Bus 



In a shared bus interface (Figure 8-18), the 80386 and the 82586 share a common address 
and data bus. The HOLD and HLDA signals provide bus arbitration. When one device 
enters the hold state in response to the HOLD input, the other device can access the bus. 

The shared bus interface is probably the simplest and least expensive interface. However, 
the performance of the 80386 may drop tremendously because the 80386 must wait for the 
82586 to complete its bus operation before it can access the bus. This wait can be several 
hundred CLK cycles. 
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CHAPTER 9 
MULTIBUS® I AND 80386 



Previous chapters have presented single-bus systems in which a single 80386 connects to 
memory, I/O, and coprocessors. This chapter introduces the system bus, which connects 
several single-bus systems to create a powerful multiprocessing system. Two examples of 
multiprocessing system buses are the Intel MULTIBUS I, discussed in this chapter, and the 
Intel MULTIBUS II, discussed in Chapter 10. 

A system bus connects several processing subsystems (each of which can include a local bus 
and private resources) and the resources that are shared between the processing subsystems. 
Because all the processing subsystems perform operations simultaneously on their respective 
local buses, such a multiprocessing system results in a significant increase in throughput over 
a single-bus system. 

Another advantage of using a system bus is that the system can be expanded modularly. The 
system bus establishes the standard interface through which additional processing subsys- 
tems communicate with one another. Through this interface, components from different 
vendors can be integrated. 

A central concern of any multiprocessing system is dividing resources between the system 
bus and the individual local buses; that is, determining which resources to share between all 
processors and which to keep for only one processor's use. These choices affect system relia- 
bility, integrity, throughput, and performance. The deciding factors are often the require- 
ments of the particular target system. 

Because local resources are isolated from failures occurring in other parts of the system, 
they enhance the overall reliability of the system. Also, because the processor does not have 
to contend with other processors for access to its local resources, bus cycles are performed 
quickly. However, local resources add to the system cost because each resource must be 
duplicated for each subsystem that requires it. 

Resources used by more than one processing subsystem but not used frequently by any 
subsystem should be placed on the system bus. The system can minimize the idle time of 
such resources. However, this advantage must be weighed against the disadvantage of 
increased access time when more than one processor must use a system resource. 



9.1 MULTIBUS® I (IEEE 796) 

The Intel MULTIBUS I (IEEE 796 Standard) is a proven, industry-standard, 16-bit multi- 
processing system bus. A wide variety of MULTIBUS I compatible I/O subsystems, memory 
boards, general purpose processing boards, and dedicated function boards are available from 
Intel. Designers who choose the MULTIBUS I protocols in their system bus have a ready 
supply of system components available for use in their products. 
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MULTIBUS I protocols are described in detail in the Intel MULTIBUS® I Architecture 
Reference Book. 

One method of constructing an interface between the 80386 and the MULTIBUS I is to 
generate all MULTIBUS I signals using only TTL and PAL devices. A simpler method is 
to use the 80286-compatible interface described in Chapter 8. The latter option is described 
in the MULTIBUS I interface example in this chapter. 

9.2 MULTIBUS® I INTERFACE EXAMPLE 

The MULTIBUS I interface presented in the following example consists of the 80286- 
compatible 82289 Bus Arbiter and 82288 Bus Controller. The 82289, along with the bus 
arbiters of other processing subsystems, coordinates control of the MULTIBUS I; the 82288 
provides the control signals to perform MULTIBUS I accesses. Communication between 
the 80386 and these devices is accomplished through PALs that are programmed to perform 
all necessary signal translation and generation. Latching and buffering of the data and address 
buses is performed by TTL logic. 

Figure 9-1 shows a block diagram of the interface, which consists of the following parts: 

AO/Al generator — Generates the lower address bits from 80386 BE0#-BE3# outputs 

Address decoder — Determines whether the bus cycle requires a MULTIBUS I access 

MULTIBUS I address latches — Connect directly to 80386 address pins A23-A2 and the 
outputs of the AO/Al generator 

MULTIBUS I data latch /transceivers— Connect directly to 80386 data pins D15-D0 

S0#/S1# generator— Translates 80386 outputs into the S0# and Sl# signals 

Wait-state generator — Controls the length of the 80386 bus cycle through the READY# 
signal 

82288 Bus Controller — Generates the MULTIBUS I command signals 

82289 Bus Arbiter — Arbitrates contention for bus control between the 80386 and other 
MULTIBUS I masters 

These elements of the 80286-compatible interface are described in detail in Chapter 8. The 
block diagram in Figure 9-1 does not include the 80386 local bus interface and local resources. 
In a complete system, some logic (for example, the address decoder) is common to both 
MULTIBUS I and local bus interfaces. The following discussion includes only the logic 
necessary for the MULTIBUS I interface. 

9.2.1 Address Latches and Data Transceivers 

MULTIBUS I allows up to 24 address lines and 16 data lines. In this example, the 
MULTIBUS addresses are located in a 256-kilobyte range between FOOOOOH and F3FFFFH, 
so that all 24 address lines are used. The 16 data lines correspond to the lower half of the 
80386 data bus. 
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Figure 9-1. 80386-MULTIBUS® I Interface 
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Inverting address latches convert the 80386 address outputs to the active-low MULTIBUS 
I address bits. MULTIBUS I address bits are numbered in hexadecimal so that A23-A0 on 
the 80386 bus become ADR17#-ADR0# on the MULTIBUS I. The BHE# signal is latched 
to provide the MULTIBUS I BHEN# signal, as shov^^n in Figure 9-2. 

MULTIBUS I requires address outputs to be valid for at least 50 nanoseconds after the 
MULTIBUS I command goes inactive; therefore, the address on all bus cycles is latched. 
The Address Enable (AEN#) output of the 82289 Bus Arbiter, which goes active when the 
82289 has control of the MULTIBUS I, is an output enable for the MULTIBUS I latches. 
The ALE# output of the 82288 latches the 80386 address for the MULTIBUS I, as shown 
in Figure 9-2. 

Inverting latch/transceivers are needed to provide active-low MULTIBUS I data bits. 
MULTIBUS I data bits are numbered in hexadecimal, so D15-D0 convert to DATF#- 
DATO#. Data is latched only on write cycles. For MULTIBUS I write cycles, the 82288 
ALE#, DEN, and DT/R# inputs can control the address latches and data latch/ 
transceivers. For MULTIBUS I read cycles, the local bus RD# signal can control the latch/ 
transceivers. If DEN were used, data contention on the 80386 local bus would result when 
a MULTIBUS I read cycle immediately followed a local write cycle. 
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Figure 9-2. MULTIBUS® I Address Latches and Data Transceivers 
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9.2.2 Address Decoder 

A MULTIBUS I system typically has both shared and local memory. I/O devices can also 
be located either on MULTIBUS I or a local bus. Therefore, the address space of the 80386 
must be allocated between MULTIBUS I and the local bus, and address decoding logic 
must be used to select one bus or the other. 

The following two signals are needed for MULTIBUS I selection: 

• Bus Size 16 (BS16#) must be returned active to the 80386 to ensure a 16-bit bus cycle. 
Additional terms for other devices requiring a 16-bit bus can be added to the BS16# PAL 
equation. 

• MULTIBUS Enable (MBEN) selects the 82288 Bus Controller and the 82289 Bus Arbiter 
on the MULTIBUS I interface. Other outputs of the decoder PAL are programmed to 
select memory and I/O devices on the local bus. 

The decoding of addresses to select either the local bus or the MULTIBUS I is straight 
forward. In the following example, the system uses the first 64 megabytes of the 80386 
memory address space, requiring 26 address lines. The MULTIBUS I memory is allocated 
to the addresses from FOOOOOH to F3FFFFH. The same PAL equation generates the two 
PAL outputs BS16# and MBEN: 

/A25 * /A24 * A23 * A22 * A21 * A20 * /A19 * /A18 

I/O resources residing on MULTIBUS I can be memory-mapped into the memory space of 
the 80386 or I/O-mapped into the I/O address space independent of the physical location 
of the devices on MULTIBUS I. The addresses of memory-mapped I/O devices must be 
decoded to generate I/O read or I/O write commands for memory references that fall within 
the I/O-mapped regions of the memory space. This technique is discussed in Chapter 8 
along with the tradeoffs between memory-mapped I/O and I/O-mapped I/O. 



9.2.3 Wait-State Generator 

The wait-state generator controls the READY# input of the 80386. For local bus cycles, the 
wait-state generator produces signal outputs that correspond to each wait state of the 80386 
bus cycle, and the PAL READY# output uses these signals to set READY# active after the 
required number of wait states. Two of the wait-state signals, WSl and WS2, are also used 
to generate S0# and SI #. 

READY# generation for MULTIBUS I cycles is linked to the Transfer Acknowledge 
(XACK#) signal, which is returned active by the accessed device on MULTIBUS I when 
the MULTIBUS I cycle is complete. For a system containing a MULTIBUS I interface as 
well as a local bus, XACK# must be incorporated into the wait-state generator to produce 
the READY# signal. The necessary logic is shown in Figure 9-3. 
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Figure 9-3. Wait-State Generator Logic 

For MULTIBUS I accesses, the wait-state generator is started by the ALE# signal from the 
82288. When XACK# goes active, it is synchronized to CLK. The resulting Asynchronous 
Ready (ARDY) signal, incorporated into the PAL equation for the READY# signal, causes 
READY# to be output between two and three CLK cycles after ARDY goes active. 



The PCLK signal, which is necessary for producing 80286-compatible wait states, is gener- 
ated by dividing the CLK signal from the 82384 by two. 



To meet the READY# input hold time requirement (25 nanoseconds) for the 82288 Bus 
Controller, the READY# signal for MULTIBUS I cycles must be two CLK cycles long. 
Therefore, two PAL equations are required to generate READY#. The first equation gener- 
ates the Ready Pulse (RDYPLSE) output. RDYPLSE is fed into the READY# equation to 
extend READY# by an additional CLK cycle. These signals are gated by MBEN and PCLK. 



RDYPLSE : = ARDY * MBEN * PCLK 



/READY := ARDY * MBEN * PCLK + RDYPLSE * MBEN 
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9.2.4 Bus Controller and Bus Arbiter 

Connections for the 82288 and 82289 are shown in Figure 9-4. The 82288 can operate in 
either local-bus mode or MULTIBUS I mode; a puUup resistor on the 82288 MB input 
activates the MULTIBUS I mode. Both the 82288 and the 82289 are selected by the MBEN 
output of the address decoder PAL. The AEN# signal from the 82289 enables the 82288 
outputs. 

Timing diagrams for MULTIBUS I read and write cycles are shown in Figures 9-5 and 
9-6. The only differences between the timings are that a read cycle controls the data latch/ 
transceivers using RD# and outputs the MRDC# command signal, whereas a write cycle 
controls the data latch/transceivers using DEN and outputs the MWTC# command. 
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Figure 9-4. MULTIBUS® Arbiter and Bus Controller 
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Figure 9-5. MULTIBUS® I Read Cycle Timing 
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Figure 9-6. MULTIBUS® I Write Cycle Timing 
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9.3 TIMING ANALYSIS OF MULTIBUS® I INTERFACE 

The timing specifications for the MULTIBUS I are explained in the MULTIBUS® I Speci- 
fication, Order Number 9800683. Table 9-1 lists the MULTIBUS I parameters that relate 
to the 80386 system. These calculations are based on the assumption that 74ALS580 latches 
and 74F544 transceivers are used for the MULTIBUS I address and data interface. 

In addition to the parameters in Table 9-1, designers must allow for the following: 

• To ensure sufficient access time for the slave device, bus operations must not be termi- 
nated until an XACK# signal is received from the slave device. 

• Following an MRDC# or an IORC# command, the responding slave device must disable 
its data drivers within 125 nanoseconds after the return of the XACK# signal. All devices 
that meet the MULTIBUS I specification of 65 nanoseconds meet this requirement. 



9.4 82289 BUS ARBITER 

In a MULTIBUS I system, several processing subsystems contend for the use of shared 
resources. If one processor requests access to MULTIBUS I while another processor is using 
it, the requesting processor must wait. Bus arbitration logic controls access to MULTIBUS 
I for all processing subsystems. 

Each processing subsystem contains its own 82289 Bus Arbiter. The Bus Arbiter directs its 
processor onto the bus and allows higher and lower priority bus masters to access the bus. 
Once the bus arbiter gains control of MULTIBUS I, the 80386 can access system resources. 
The bus arbiter handles bus contention in a manner that is transparent to the 80386. 



Table 9-1. MULTIBUS® I Timing Parameters 



Timing 
Parameter 


MULTIBUS 
Specification 


80386 System 
Timing 


tAS 

Address setup 

before command 

active 


50 ns 
minimum 


125 ns (2 CLK cycles) 

- 20 ns (ALE max delay) 

- 22 ns (74ALS580 max. delay) 
+ 3 ns (Command min. delay) 

86 ns min. 


tDS 

Write data 
setup before 
command active 


50 ns 
minimum 


125 ns (2 CLK cycles) 

- 30 ns (DEN max. delay) 

- 12 ns (74F544 max. delay) 
+ 3 ns (Command min. delay) 

86 ns min. 


tAH 

Address hold 
after command 
Inactive 


50 ns 
minimum 


187.5ns (3 CLK cycles) 
- 25 ns (Command inactive max. delay) 
+ 3 ns (ALE max. delay) 

165.5ns min 
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Each processor in the multiprocessing system initiates bus cycles as though it has exclusive 
use of MULTIBUS I. The bus arbiter keeps track of whether the subsystem has control of 
the bus and prevents the bus controller from accessing the bus when the subsystem does not 
control the bus. 

When the bus arbiter receives control of MULTIBUS I, it enables the bus controller and 
address latches to drive MULTIBUS I. When the transfer is complete, MULTIBUS I returns 
the XACK# signal, which activates READY# to end the bus cycle. 



9.4.1 Priority Resolution 

Because a MULTIBUS I system includes many bus masters, logic must be provided to resolve 
priority between two bus masters that simultaneously request control of MULTIBUS I. 
Figure 9-7 shows two common methods for resolving priority: serial priority and parallel 
priority. 

The serial priority technique is implemented by daisy-chaining the Bus Priority In (BPRN#) 
and Bus Priority Out (BPRO#) signals of all the bus arbiters in the system. Due to delays 
in the daisy chain, this technique accommodates only a limited number of bus arbiters. 

The parallel priority technique requires external logic to recognize the BPRN# inputs from 
all bus arbiters and return the BPRO# signal active to the requesting bus arbiter that has 
the highest priority. The number of bus arbiters accommodated with this technique depends 
on the complexity of the decoding logic. 

Priority resolution logic need not be included in the design of a single processing subsystem 
with a MULTIBUS I interface. The bus arbiter takes control of MULTIBUS I when the 
BPRN# signal goes active and relinquishes control when BPRN# goes inactive. As long as 
external logic exists to control the BPRN# inputs of all bus arbiters, a subsystem can be 
designed independent of the priority resolution circuit. 



9.4.2 82289 Operating Modes 

Following a MULTIBUS I cycle, the controlling bus arbiter can either retain bus control or 
release control so that another bus master can access the bus. Three modes for relinquishing 
bus control are as follows: 

• Mode 1 — The bus arbiter releases the bus at the end of each cycle. 

• Mode 2 — The bus arbiter retains control of the bus until another bus master (of any 
priority) requests control. 

• Mode 3 — The bus arbiter retains control of the bus until a higher priority bus master 
requests control. 

In addition, the bus arbiter can switch between modes 2 and 3, based on the type of bus 
cycle. 
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Figure 9-7. Bus Priority Resolution 
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Figure 9-8 shows the strapping configurations required to implement each of these four 
techniques. 

The operating mode of one bus arbiter affects the throughput of both the individual subsys- 
tem as well as other subsystems on MULTIBUS I. This is because the delay required to 
transfer MULTIBUS I control from one bus arbiter to another affects all subsystems waiting 
to use MULTIBUS I. Therefore, the most efficient operating mode depends on how often a 
subsystem accesses MULTIBUS I and how this frequency compares to that of the other 
subsystems. 

• Mode 1 is adequate for a subsystem that needs MULTIBUS I access only occasionally. 
By releasing MULTIBUS I after each bus cycle, the subsystem minimizes its impact on 
other subsystems that use MULTIBUS L 
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Figure 9-8. Operating Mode Configurations 
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Mode 2 is suited for a subsystem that is one of several subsystems that are all equally 
likely to require MULTIBUS I. The performance decrease caused by the delay necessary 
to take control of MULTIBUS I is distributed evenly to all subsystems. 

Mode 3 should be used for a subsystem that uses MULTIBUS I frequently. The delay 
required for taking control of MULTIBUS I and the consequent performance decrease is 
shifted to subsystems that use MULTIBUS I less often. 

Svi^itching between modes 2 and 3 is useful if the subsystem demand for MULTIBUS I 
is unknown or variable. 



9.4.3 MULTIBUS® I Locked Cycles 

Locked bus cycles for the local bus are described in Chapter 3. In locked bus cycles, the 
80386 asserts the LOCK# signal to prevent another bus master from intervening between 
two bus cycles. In the same manner, an 80386 processing subsystem can assert the LLOCK# 
output of its bus arbiter to prevent other subsystems from gaining control of MULTIBUS 
I. A locked cycle overrides the normal operating mode of the bus arbiter (one of the four 
modes mentioned above). 

Locked MULTIBUS I cycles are typically used to implement software semaphores (described 
in Chapter 3) for critical code sections or critical real-time events. Locked cycles can also 
be used for high-performance transfers within one instruction. 

The 80386 initiates a locked MULTIBUS I cycle by asserting its LOCK# output to the 
82289 bus arbiter. The bus arbiter outputs its LLOCK# signal to the MULTIBUS I LOCK# 
status line and holds LLOCK# active until the LOCK# signal from the 80386 goes inactive. 
The LLOCK# signal from the bus arbiter must be connected to the MULTIBUS I LOCK# 
status line through a tristate driver controlled by the AEN# output of the bus arbiter. 



9.5 OTHER MULTIBUS® I DESIGN CONSIDERATIONS 

Additional design considerations are presented in this section. These considerations include 
provisions for interrupt handling, 8-bit transfers, timeout protection, and power failure 
handling on MULTIBUS I. 



9.5.1 Interrupt-Acknowledge on MULTIBUS® I 

When an interrupt is received by the 80386, the 80386 generates an interrupt-acknowledge 
cycle (described in Chapter 3) to fetch an 8-bit interrupt vector from the 8259A Program- 
mable Interrupt Controller. The 8 259 A can be located on either MULTIBUS I or a local 
bus. 
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Multiple 8259As can be cascaded (one master and up to eight slaves) to process up to 64 
interrupts. Three configurations are possible for cascaded interrupt controllers: 

• All of the interrupt controllers for one 80386 reside on the local bus of that processor, 
and all interrupt-acknowledge cycles are directed to the local bus. 

• All slave interrupt controllers (those that connect directly to interrupting devices) reside 
on MULTIBUS I. The master interrupt controller may reside on either the local bus or 
MULTIBUS I. In this case, all interrupt-acknowledge cycles are directed to 
MULTIBUS I. 

• Some slave interrupt controllers reside on local buses, and other slave interrupt control- 
lers reside on MULTIBUS I. In this case, the appropriate bus for the interrupt- 
acknowledge cycle depends on the cascade address generated by the master interrupt 
controller. 

In the first two configurations, no decoding is needed because all interrupt acknowledge 
cycles are directed to one bus. However, if a system contains a master interrupt controller 
residing on a local bus and at least one slave interrupt controller residing on MULTIBUS I, 
address decoding must select the bus for each interrupt-acknowledge cycle. 

The interrupt-acknowledge cycle must be considered in the design of this decoding logic. 
The 80386 responds to an active INTR input by performing two bus cycles. During the first 
cycle, the master interrupt controller determines which, if any, of its slave controllers should 
return the interrupt vector and drive sits cascade address pins (CASO#, CAS1#, CAS2#) to 
select that slave controller. During the second cycle, the 80386 reads an 8-bit vector from 
the selected interrupt controller and uses this vector to service the interrupt. 

In a system that has slave controllers residing on MULTIBUS I, the circuit shown in 
Figure 9-9 can be used to decode the three cascade address pins from the master controller 
to select either MULTIBUS I or the local bus for the interrupt-acknowledge cycle. If 
MULTIBUS I is selected, the 82289 Bus Arbiter is enabled. The 82289 in turn requests 
control of MULTIBUS I and enables the address and data transceivers when the request is 
granted. 

The bus-select signal must become valid for the second interrupt-acknowledge cycle. The 
master controller's cascade address outputs become valid within 565 nanoseconds after the 
INTA# output from the bus control logic goes active. Bus-select decoding requires 30 
nanoseconds, for a total of 595 nanoseconds from INTA# to bus-select valid. The four idle 
bus cycles that the 80386 automatically inserts between the two interrupt-acknowledge cycles 
provides some of this time. The wait-state generator must add wait states to the first 
interrupt-acknowledge cycle to provide the rest of the time needed for the bus-select signal 
to become valid. 

The cascade address outputs are gated onto A8, A9, and AlO of the address bus through 
three-state drivers during the second interrupt-acknowledge cycle. Bus control logic must 
generate a Master Cascade Enable (MCE) signal to enable these drivers. This signal must 
remain valid long enough for the cascade address to be captured in MULTIBUS I address 
latches; however it must be de-asserted before the 80386 drives the address bus. 
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Figure 9-9. Bus-Select Logic for Interrupt Acknowledge 



9.5.2 Byte Swapping during {MULTIBUS® I Byte Transfers 



The MULTIBUS I standard specifies that all byte transfers must be performed on the lower 
eight data lines (MULTIBUS I DAT0#-DAT7#), regardless of the address of the data. An 
80386 subsystem must swap data from eight of its upper 24 data lines (D8-D15, D16-D23, 
or D24-D31) to its lower eight data lines (D0-D7) before transferring data to MULTIBUS 
I, and swap data from its lower data lines to the appropriate upper data lines when reading 
a byte from MULTIBUS I. This byte-swapping requirement maintains compatibility between 
8-bit, 16-bit, and 32-bit systems sharing the same MULTIBUS I. 
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The BS16# signal is generated and returned to the 80386 for all MULTIBUS I cycles. The 
80386 automatically swaps data between the lower half (D15-D0) and the upper half 
(D31-D16) of its data bus and adds an extra bus cycle as necessary to complete the data 
transfer. Therefore, only the logic to swap data from D15-D8 to D7-D0 is needed to meet 
the byte-swapping requirement of MULTIBUS I. 

Figure 9-10 illustrates a circuit that performs the byte-swapping function. The Output Enable 
(OE#) inputs of the data latch/transceivers are conditioned by the states of the BHE# and 
AC outputs of the address decoder. 



9.5.3 Bus Timeout Function for MULTIBUS® I Accesses 

The MULTIBUS I XACK# signal terminates an 80386 bus cycle by driving the wait-state 
generator logic. However, if the 80386 addresses a nonexistent device on MULTIBUS I, the 
XACK# signal is never generated. Without a bus-timeout protection circuit, the 80386 waits 
indefinitely for an active READY# signal and prevents other processors from using 
MULTIBUS I. 

Figure 9-11 shows an implementation of a bus-timeout circuit that ensures that all 
MULTIBUS I cycles eventually end. The ALE# output of the bus controller activates a 
one-shot that outputs a 1 -millisecond pulse. The rising edge of the pulse activates the 
TIMEOUT# signal if READY# does not go active within 1 millisecond to clear the 
TIMEOUT# flip-flop. The TIMEOUT# signal is input to the wait-state generator logic to 
activate the READY# signal. When READY# goes active, it is returned to clear the 
TIMEOUT# signal. 



9.5.4 MULTIBUS® I Power Failure Handling 

The MULTIBUS I interface includes a Power Fail Interrupt PFIN signal to signal an 
impending system power failure. Typically, PFIN# is connected to the non-maskable inter- 
rupt (NMI) request input of each 80386. The NMI service routine can direct the 80386 to 
save its environment immediately, before falling voltages and the MULTIBUS I Memory 
Protect (MPRO#) signal prevent any further memory activity. In systems with memory 
backup power or nonvolatile memory, the saved environment can be recovered on powerup. 

The power-up sequence of the 80386 can check the state of the MULTIBUS I Power Fail 
Sense Latch (PFSN#) to see if a previous power failure has occurred. If this signal is active 
(low), the 80386 can branch to a power-up routine that resets the latch using the Power Fail 
Sense Reset signal (PFSR#), restores the previous 80386 environment, and resumes 
execution. 

Further guidelines for designing 80386 systems with power failure features are contained in 
the Intel MULTIBUS® I Specification. 
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Figure 9-10. Byte-Swapping Logic 



9.6 iLBX"^ BUS EXPANSION 



The iLBX (Local Bus Expansion) is a high-performance bus interface standard that permits 
the modular expansion of an 80386-based system. An iLBX interface links the 80386 system 
board with additional boards containing memory, I/O subsystems, and other peripheral 
devices or bus masters. Any board that conforms to the iLBX standard can be added to the 
system as the user's needs dictate. For a 16-MHz 80386-based system, a typical iLBX access 
cycle requires six wait states. 
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Figure 9-11. Bus-Timeout Protection Circuit 

The iLBX^ Bus Specification describes the iLBX Local Bus Expansion standard in detail. 

The iLBX bus interface requires the generation of Al, AO, and BHE# from the 80386 
BE3#-BE0# outputs. The iLBX connector contains 24 address bits (AB23-AB0) and 16 data 
bits (DB15-DB0), which are taken from the buffered address lines (A23-A0), and data lines 
(D15-D0) of the 80386 local bus. BHE# is inverted and buffered to provide the Byte High 
Enable (BHEN) signal. 

The Read/Write (R/W#), Data Strobe (DSTB#), and Address Strobe (ASTB#) controls 
are generated from local bus control signals using the logic shown in Figure 9-12. R/W# is 
a delayed, inverted version of the W/R# output of the 80386. DSTB# goes active when 
either RD# or WR# from the local bus control goes active. ASTB# and DSTB# are delayed 
to allow adequate setup time for BHEN. In this example, the WS2 signal, which is active 
during the third CLK cycle of the 80386 bus cycle, provides the delay. 

A chip-select output of address decoding logic goes active for accesses to the memory and 
I/O locations allocated to the iLBX bus and selects the iLBX address and data buffers. 
Command signals from the local bus control logic enable the outputs of the iLBX 
transceivers. 

When an iLBX cycle is complete, the Acknowledge (ACK#) signal is returned over the 
iLBX bus. This signal must be synchronized and incorporated into the wait-state generator 
logic to provide the READY# signal. 



9.7 DUAL-PORT RAM WITH MULTIBUS® I 

A dual-port RAM is a memory subsystem that can be accessed by both the 80386, through 
its local bus, and other processing subsystems, through the MULTIBUS I system bus. Dual- 
port RAM offers some of the advantages of both local resources and system resources. It is 
an effective solution when using only local memory or only system memory would decrease 
system cost and /or performance significantly. 
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Figure 9-12. iLBX^'^ Signal Generation 

The 80386 accesses dual-port RAM through its high-speed local bus, leaving MULTIBUS 
I free for other system operations. Other processing subsystems can pass data to and from 
the 80386 through the dual-port RAM using MULTIBUS I. 

If necessary, dual-port RAM can be mapped to reserve address ranges for the exclusive use 
of the 80386. The 80386 and the other processing subsystems need not use the same address 
mapping for dual-port RAM. 

The disadvantage of dual-port RAM is that its design is more complex than that of either 
local or system memory. Dual-port RAM requires arbitration logic to ensure that only one 
of the two buses gains access at one time. 



9.7.1 Avoiding Deadlock with Dual-Port RAM 

The MULTIBUS-LOCK# signal and the 80386 LOCK# signal mediate contention when 
both the 80386 and a MULTIBUS I device attempt to access dual-port RAM. However, 
locked cycles to dual-port RAM can potentially result in deadlock. Deadlock arises when 
the 80386 performs locked cycles to ensure back- to-back accesses to dual-port RAM and 
MULTIBUS I. 
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Suppose the 80386 locks an access to dual-port RAM followed by a MULTIBUS access, to 
ensure that the accesses are performed back-to-back. (This could happen only in protected 
mode during interrupt processing when the IDT is in the dual-port RAM and the target 
descriptor is in MULTIBUS RAM.) At the same time the 80386 performs the first locked 
cycle, another device gains control of MULTIBUS I for the purpose of accessing dual-port 
RAM. The 80386 cannot gain control of MULTIBUS I to complete the locked operation, 
and the other device cannot relinquish control of MULTIBUS I because it cannot complete 
its access to dual-port RAM. Each device therefore enters an interminable wait state. 

Two approaches can be used to avoid deadlock: 

• Requiring software to be free of locked accesses to dual-port RAM. 

• Designing hardware to negate the LOCK# signal for transfers between dual-port RAM 
and MULTIBUS I. If this approach is used, software writers must be informed that such 
transfers will not be locked even though software dictates locked cycles. 
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CHAPTER 10 
MULTIBUS® II AND 80386 



Standard bus interfaces guarantee compatibility between existing and newly developed 
systems. This compatibility safeguards a user's hardware investment against obsolescence 
even in the face of rapidly advancing technology. The MULTIBUS I standard interface has 
proven its value in providing flexibility for the expansion of existing systems and the integra- 
tion of new designs. The MULTIBUS II standard interface extends Intel's Open Systems 
design strategy into the world of 32-bit microprocessing systems. 



10.1 MULTIBUS® II STANDARD 

The MULTIBUS II standard is a processor-independent bus architecture that features a 
32-bit parallel system bus with a maximum throughput of 40 megabytes per second, high- 
speed local bus access to off-board memory, a low-cost serial system bus, and full multi- 
processing support. MULTIBUS II achieves these features through five specialized Intel 
buses: 

• Parallel System Bus (iPSB) 

• Local Bus Extension (iLBX II) 

• Serial System Bus (iSSB) 

• Multi-channel DMA I/O Bus 

• System Expansion I/O Bus (iSBX) 

The DMA I/O Bus and the iSBX are carried over directly from MULTIBUS I architecture. 
See the MULTIBUS® I Architectural Specification for a full description of these buses. The 
multiple bus structure provides the following important advantages over a single, generalized 
bus: 

• Each bus is optimized for a specific function. 

• The buses perform operations in parallel. 

• Buses that are not needed for a particular system can be omitted, avoiding unnecessary 
costs. 



10.2 PARALLEL SYSTEM BUS (iPSB) 

The Parallel System Bus UPSB) is optimized for interprocessor data transfer and commu- 
nication. Its burst transfer capability provides a maximum sustained bandwidth of 40 
megabytes per second for high-performance data transfers. 
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The iPSB supports four address spaces per bus agent (a board that encompasses a functional 
subsystem). The conventional I/O and memory address spaces are included, plus two other 
address spaces that support advanced functions: 

• An 255 address message space supports message passing. Typically, a microprocessor 
performs interprocessor communications inefficiently. Message passing allows two bus 
agents to exchange a block of data at full bus bandwidth without supervision from a 
microprocessor. An intelligent bus interface capable of message passing shifts the burden 
of interprocessor communication away from the processor, thus enhancing overall system 
performance. 

• An interconnect space allows geographic addressing, which is the identification of any 
bus agent (board) by slot number. Every MULTIBUS II system contains a Central 
Services Module (CSM) that provides system services, such as uniform initialization and 
bus timeout detection, for all bus agents residing on the iPSB bus. The CSM may use the 
registers of the interconnect space of each bus agent to configure the agent dynamically. 
Stake pin jumpers, DIP switches, and other hardware configuration devices can be 
eliminated. 

Because the 80386 can access only memory space or I/O space, the message space and 
interconnect space may be mapped into the memory space or the I/O space. Decoding logic 
provides chip select signals for the devices implementing the message space and the inter- 
connect space, as well as devices in the memory space and the I/O space. 

Three types of bus cycles define activity on the iPSB bus: 

• Arbitration Cycle — Determines the next owner of the bus. This cycle consists of a resolu- 
tion phase, in which competing bus agents determine priority for bus control, and an 
acquisition phase, in which the agent with the highest priority initiates a transfer cycle. 

• Transfer Cycle — Performs a data transfer between the bus owner and another bus agent. 
This cycle consists of a request phase, in which address control signals are driven, and a 
reply phase, in which the two agents perform a handshake to synchronize the data trans- 
fer. The reply phase is repeated and data transfers continue until the bus owner ends the 
transfer cycle. 

• Exception Cycle — Indicates that an exception (error) has occurred during a transfer cycle. 
This cycle consists of a signal phase, in which an exception signal from one bus agent 
causes all other bus agents to terminate any arbitration and transfer cycles in progress, 
and a recovery phase, in which the exception signals go inactive. A new arbitration cycle 
can begin on the clock cycle after the recovery phase. 

Figure 10-1 shows how the timing of these cycles overlap. 

10.2.1 iPSB Interface 

Each bus agent must provide a means of transferring data between its 80386, its intercon- 
nect registers, and the iPSB bus. The location of bus interface logic to meet this requirement 
is shown in Figure 10-2. A full- featured subsystem may also include provisions for the message 
passing protocols used by the iPSB bus. 
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Figure 10-1. IPSB Bus Cycle Timing 
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Figure 10-2. iPSB Bus Interface 



The iPSB interface may be conveniently implemented by a Bus Arbiter/ Controller (BAC), 
a Message Interrupt Controller (MIC), and miscellaneous logic. The BAC coordinates direct 
interaction with the other devices on the iPSB bus, while the MIC works through the BAC 
to send and receive interrupt messages. Other logic is needed for address decoding, parity 
checking, and control signal generation. 

The BAC and MIC are implemented in Intel gate arrays. In addition, Intel is developing an 
advanced CMOS device, the Message Passing Coprocessor (MPC), that integrates the 
functions of the BAC and the MIC plus parity checking and full message passing (solicited 
and unsolicited), all in one package called the BIC (Bus Interface Controller). Systems 
designed today with the available BAC and MIC can be upgraded to the MPC in the future. 



10.2.1.1 BAC SIGNALS 

The BAC provides arbitration and system control logic for the arbitration, transfer, and 
exception cycles defined by the MULTIBUS II architecture. Through the BAC, the bus 
agent functions as either a requestor or a replier in a transfer cycle. In all cases, the device 
requiring iPSB bus access (either the 80386 or the MIC) is completely isolated from the 
iPSB; the BAC provides all direct interaction. 
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The BAC signals can be divided into three functional groups: 

• iPSB interface 

• Local bus interface 

• Register interface with the 80386 

The iPSB interface signals perform mainly arbitration and system control. Five bidirectional 
Arbitration signals (ARB5-ARB0) are used during reset to read a cardslot ID and arbitra- 
tion ID from the CSM, and during arbitration cycles to output the arbitration ID for prior- 
ity resolution. Bus Request (BREQ#) is a bidirectional signal. Each bus agent asserts BREQ# 
to request control of the bus and samples BREQ# to determine if other agents are also 
contending for bus control. 

Bus Error (BUSERR#) is a bidirectional signal that a bus agent outputs to all other bus 
agents when it detects a parity error during a transfer cycle. Bus Timeout (TIMOUT #) is 
output by the CSM to all bus agents when a bus cycle fails to end within a prescribed time 
period. 

Ten System Control signals (SC9#-SC0#) coordinate transfer cycles. The MULTIBUS® II 
Architectural Specification defines each of these signals. Directional enables (SCOEH and 
SCOEL) are provided for transceivers to buffer these bidirectional signals. External logic 
checks byte parity on the multiplexed address and data bus (ADS 1 -ADO) and sets the Parity 
inputs (PAR3-PAR0) accordingly. 

Other iPSB signals are Reset (RST#), Reset-Not-Complete (RSTNC#), and ID Latch 
(LACHn#, n = slot number). These signals are used only during reset. 

Local bus interface signals pertain to the communication between the BAC and the 80386 
or between the BAC and the MIC. These signals indicate to the BAC when to request bus 
control and what type of bus cycle to drive when it gains bus control. 

Four control signals are necessary for each of the two devices connected to the BAC. The 
signals that connect to the 80386 are REQUESTA, GRANTA, READYA, and SELECTA; 
those that connect to the MIC are REQUESTB, GRANTB, READYB, and SELECTB. 

To request bus control, the 80386 or the MIC activates one of the REQUEST signals. The 
corresponding GRANT signal is returned by the BAC when it has bus control. Data width 
and address space selections are encoded on the WIDTH 1#, WIDTHO#, SPACE 1#, and 
SPACEO# inputs, while WR# dictates either a write cycle or a read cycle. These five inputs 
translate directly to SC6#-SC2# outputs during the request phase of a transfer cycle. 
READYA or READYB indicates that WIDTHO#, WIDTH1#, SPACEO#, SPACE1#, and 
WR# can be read by the BAC to drive the transfer cycle. 

LASTINA or LASTINB controls the end-of-cycle signal for burst transfers. The LOCK# 
input is activated for locked transfers. 
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The bus agent that receives a transfer cycle from the bus owner must have its BAC enabled 
by an active SELECT input. Errors detected by the replying agent are encoded by its MIC 
on the AGERR2-ACERR0 inputs to its BAC so that the BAC can drive the SC7fSC5# 
lines accordingly. If an error occurs, the requesting agent notifies the 80386 through the 
EINT signal. 

The register interface signals control register operations between the 80386 and the BAC. 
Three 5-bit registers (Arbitration ID, Slot ID, and Error Port) are addressed through RSELl 
and RSELO. Data is transferred on RIO4-RIO0; the direction of transfer is indicated by 
RRW. 

10.2.1.2 MIC SIGNALS 

The MIC coordinates interrupt handling for a bus agent on the iPSB bus. Interrupts are 
implemented as virtual interrupts in the message space. To send an interrupt message, the 
80386 writes four bytes to the MIC to indicate the source, destination, and type of message. 
The MIC then coordinates the message transfer. The MIC of the receiving bus agent reads 
the 4-byte message and stores it in a 4-deep message queue to be read by the 80386. 

The MIC signals are divided into three groups: 

• iPSB interface 

• Local bus interface 

• BAC interface 

The iPSB interface consists of the multiplexed address/data bus (AD31#-AD0#). Although 
the MIC gains access to the iPSB bus through the BAC, the MIC drives the address/data 
bus directly. As a requesting agent, the MIC drives the address and data at the appropriate 
times. As a receiving agent, the MIC monitors the address/data bus for its address. When 
it recognizes its address, the MIC selects its BAC to perform the required handshake and 
read the message into the message queue. Then, the MIC interrupts the 80386 to indicate 
that the message is pending in the queue. The 80386 reads the message and services the 
interrupt accordingly. 

The local bus interface consists of seven register /ports, addressed through A2-A0, through 
which the MIC and the 80386 communicate. Data is transferred over D7-D0, and WR# and 
RD# determine the direction of transfer. Other signals include the MIC Chip Select (CS#), 
a WAIT# signal for adding wait states to the 80386 cycle, and a Message Interrupt (MINT) 
to signal an interrupt condition to the 80386. 

The BAC interface includes REQUESTB, READYB, SELECTB, and GRANTB. These 
signals have already been described with the other BAC signals. 

While the BAC and the MIC together provide the backbone for an iPSB interface, other 
logic provides buffering and control to round out the interface. An 8751 Microcontroller 
coordinates 80386 access to the interconnect space. An address decoder distinguishes between 
local, interconnect, and iPSB accesses. PALs control the buffering of signals between the 
80386, BAC, MIC, 8751 Microcontroller, and iPSB bus. 
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10.3 LOCAL BUS EXTENSION (iLBX^^ II) 

The iLBX II bus extension is a high-speed execution bus designed for quick access to off- 
board memory. One iLBX II bus extension can support either two processing subsystems 
(called the primary requesting agent and the secondary requesting agent) plus four memory 
subsystems, or a single processing subsystem plus five memory subsystems. A MULTIBUS 
II system may contain more than one iLBX II bus extension to meet its memory 
requirements. 

The iLBX II bus extension features a 26-bit address bus and a separate 32-bit data bus. 
Because these paths are separate, the extension allows pipelining of transfer cycles; the request 
phase of a transfer cycle can overlap the reply phase of the previous cycle. 

Other features of the iLBX II bus extension are: 

• A unidirectional handshake for fast data transfers 

• Mutual exclusion capability to control multiported memory 

• Interconnect space (for each bus agent) through which the primary requesting agent 
initializes and configures all other bus agents. 

10.4 SERIAL SYSTEM BUS (iSSB) 

The Serial System Bus (iSSB) provides a simple, low-cost alternative to the Parallel System 
Bus (iPSB) bus. In applications that do not require the high performance of the iPSB bus, 
the iSSB bus can provide some cost reduction. In systems containing both the iPSB bus and 
the iSSB bus, the iSSB bus provides an alternate path for interface control, diagnostics, or 
redundancy. 

The iSSB bus can contain up to 32 bus agents distributed over a maximum of 10 meters. 
Bus control is determined through an access protocol called Carrier Sense Multiple Access 
with CoUision Detection (CSMA/CD). This protocol allows agents to transmit data whenever 
they are ready. In case of simultaneous transmission by two or more bus agents, the iSSB 
invokes a deterministic collision resolution algorithm to grant fair access to all agents. 

From the application point of view, the error detection capability of the iSSB bus, coupled 
with an intelligent bus agent interface (able to retransmit) makes the iSSB bus as reliable 
as the iPSB bus, even though the iSSB bus may be up to 10 meters long. 
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CHAPTER 11 
PHYSICAL DESIGN AND DEBUGGING 



This chapter outlines recommendations for providing adequate power to the 80386, address- 
ing high-frequency issues that do not exist for lower-frequency systems, achieving the proper 
thermal environment for the 80386, and building an 80386-based system successfully. The 
guidelines presented here allow the user to gain the full benefits of the high-performance 
80386. 



11.1 POWER AND GROUND REQUIREMENTS 

The CHMOS III 80386 differs from previous HMOS microprocessors in that its power 
dissipation is primarily capacitive; there is almost no DC power dissipation. Power dissipa- 
tion depends mostly on frequency. 

Power dissipation can be distinguished as either internal (logic) power or I/O (bus) power. 
Internal power varies with operating frequency and to some extent with wait states and 
software. Internal power increases with supply voltage also. Process variations in manufac- 
turing affect internal power, although to a lesser extent than with NMOS processes. 

I/O power, which accounts for roughly one-fifth of the total power dissipation, varies with 
freouency and voltage. It also depends on capacitive bus load. Capacitive bus loading for 
normal AC performance is specified in the 80386 data sheet. Performance will be reduced 
if these loadings are exceeded. The addressing pattern of the software can affect I/O power 
by changing the effective frequency at the address pins. (Data interactions comprise a 
relatively small percentage of I/O; the variation in frequency at the data pins with different 
data patterns is not a significant factor in power dissipation.) 



11.1.1 Power and Ground Planes 

Power and ground planes must be used in 80386 systems to minimize noise. Power and 
ground lines have inherent inductance and capacitance, therefore an impedance 
Z = (L/C)^/^. The total characteristic impedance for the power supply can be reduced by 
adding more lines. This effect is illustrated in Figure 11-1, which shows that two lines in 
parallel have half the impedance of one. To reduce the impedance even further, the user 
should add more lines. In the limit, an infinite number of parallel lines, or a plane, results 
in the lowest impedance. Planes also provide the best distribution of power and ground. 

The 80386 has 20 V^c pins and 21 V^^ (ground) pins. All power and ground pins must be 
connected to a plane. Ideally, the 80386 is located at the center of the board, to take full 
advantage of these planes. 

Although the 80386 generally demands less power than the 80286, the possibility for power 
surges is increased due to higher frequency and pin count. Peak-to-peak noise on V^c relative 
to V^s should be maintained at no more than 400 mV, and preferably no more than 200 mV. 
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11.1.2 Decoupling Capacitors 

The switching activity of one device can propagate to other devices through the power supply. 
For example, in the TTL NAND gate of Figure 11-2, both Q3 and Q4 transistors are on for 
a short time when the output is switching. This increased load causes a negative spike on V^^ 
and a positive spike on ground. In synchronous systems in which many gates switch simul- 
taneously, the result is significant noise on the power and ground lines. 
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Figure 11-1. Reducing Characteristic Impedance 




Figure 11-2. Circuit without Decoupling 
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Decoupling capacitors placed across the device between V^c and ground reduce voltage spikes 
by supplying the extra current needed during switching. These capacitors should be placed 
close to their devices because the inductance of connection lines negates their effect. 



When selecting decoupling capacitors, the user should provide 0.01 microfarads for each 
device and 0.1 microfarads for every 20 gates. Radio-frequency capacitors must be used; 
they should be distributed evenly over the board to be most effective. In addition, the board 
should be decoupled from the external supply line with a 2.2 microfarads capacitor. 



Chip capacitors (surface-mount) are preferable because they exhibit lower inductance and 
require less total board space. They should be connected as in Figure 11-3. Leaded capaci- 
tors can also be used if the leads are kept as short as possible. Six leaded capacitors are 
required to match the effectiveness of one chip capacitor, but because only a limited number 
can fit around the 80386, the configuration in Figure 11-4 results. 



11.2 HIGH-FREQUENCY DESIGN CONSIDERATIONS 



At high signal frequencies, the transmission line properties of signal paths in a circuit must 
be considered. Reflections, interference, and noise become significant in comparison to the 
high-frequency signals. They can cause false signal transitions, data errors, and input voltage 
level violations. These errors can be transient and therefore difficult to debug. In this section, 
some high-frequency design issues are discussed; for more information, consult a reference 
book on high-frequency design. 




Figure 11-3. Decoupling Chip Capacitors 
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Figure 11-4. Decoupling Leaded Capacitors 

11.2.1 Line Termination 

Input voltage level violations are usually due to voltage spikes that raise input voltage levels 
above the maximum limit (overshoot) and below the minimum limit (undershoot). These 
voltage levels can cause excess current on input gates that results in permanent damage to 
the device. Even if no damage occurs, most devices are not guaranteed to function as speci- 
fied if input voltage levels are exceeded. 

Signal lines are terminated to minimize signal reflections and prevent overshoot and under- 
shoot. If the round-trip signal path delay is greater than the rise time or fall time of the 
signal, terminate the Une. If the line is not terminated, the signal reaches its high or lov^ 
level before reflections have time to dissipate, and overshoot and undershoot occur. 

There are tw^o methods of termination: series and split. A series termination compensates for 
excess current before the signal travels dov^n the line; a split termination adjusts the current 
at the end of the line. 

Series termination decreases current flow in the signal path by adding a series resistor, as 
shown in Figure 1 1-5. The resistor increases the rise and fall times of the signal so that the 
change in current occurs over a longer period of time. Because the amount of voltage 
overshoot and undershoot depends on the change in current over time (V = L di/dt), the 
increased time reduces overshoot and undershoot. Placing the series resistor close to the 
signal source decreases inductance (L). 

Series termination is advantageous because less power is consumed than in split termination. 
However, series termination reduces signal rise and fall times, so it should not be used when 
these times are critical. 
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Split termination is effective in reducing signal reflection (ringing). Split termination is 
accomplished by the addition of two resistors, as shown in Figure 1 1-6. As the line voltage 
starts to rise above V^^, R2 siphons off some of the current. As the Une voltage starts to drop 
below ground, current is supplied to the circuit through Rl. 



11.2.2 Interference 

Interference is the result of electrical activity in one conductor causing transient voltages to 
appear in another conductor. Interference increases with the following factors: 

• Frequency-Interference is the result of changing currents and voltages. The more frequent 
the changes, the greater the interference. 

• Closeness of the two conductors — Interference is due to electromagnetic and electrostatic 
fields whose effects are weaker further from the source. 

There are two types of interference to consider in high frequency circuits: electromagnetic 
interference (EMI) and electrostatic interference (ESI). 
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Figure 11-5. Series Termination 
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Figure 11-6. Split Termination 
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EMI (also called crosstalk) is caused by the magnetic field that exists around any current- 
carrying conductor. The magnetic flux from one conductor can induce current in another 
conductor, resulting in transient voltage. Several precautions can minimize EMI: 



• Running a ground line between tv^o adjacent lines wherever they traverse a long section 
of the circuit board. The ground line should be grounded at both ends. 

• Running ground lines between the lines of an address bus or a data bus if either of the 
following conditions exists: 

- The bus is on an external layer of the board. 

- The bus is on an internal layer but not sandwiched between power and ground planes 
that are at most 10 mils away. 

• Avoiding closed loops in signal paths (see Figure 11-7). Closed loops cause excessive 
current and create inductive noise, especially in the circuitry enclosed by a loop. 



ESI is caused by the capacitive coupling of two adjacent conductors. The conductors act as 
the plates of a capacitor; a charge built up on one induces the opposite charge on the other. 
The following steps reduce ESI: 



• Separating signal lines so that capacitive coupling becomes negligible. 

• Running a ground line between two two lines to cancel the electrostatic fields. 




Figure 1 1-7. Avoid Closed-Loop Signal Paths 
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11.2.3 Latchup 

Latchup is a condition in a CMOS circuit in which Vec becomes shorted to V^^. Intel's 
CHMOS III process prevents latchup under normal operating conditions. Latchup can be 
triggered when the voltage limits on I/O pins are exceeded, causing current surges. The 
following guidelines help prevent latchup: 

• Observing the maximum rating for input voltage on I/O pins. 

• Never applying power to an 80386 pin or a device connected to an 80386 pin before 
applying power to the 80386 itself. 

• Preventing overshoot and undershoot on I/O pins by adding Une termination and by 
designing to reduce noise and reflection on signal lines. 



1 1.3 CLOCK DISTRIBUTION AND TERMINATION 

For performance at high frequencies, the clock signal (CLK2) for the 80386 must be free of 
noise and within the specifications listed in the 80386 data sheet. These requirements can be 
met by following these guidelines: 

• Using the 82384 Clock Generator to provide both CLK2 and CLK signals. The 82384 is 
designed to match 80386 specifications. 

• Terminating the CLK2 output with a series resistor to obtain a clean signal. The resistor 
value is calculated by measuring the total capacitive load on the CLK2 signal and refer- 
ring to Figure 11-8. If the total capacitive load is less than 80 picofarads, the user should 
add capacitors to make up the difference. Because of the high frequency of CLK2, the 
terminating resistor must have low inductance; carbon resistors are recommended. 

• Not putting more than two loads on a single trace to avoid signal reflection (see 
Figure 11-9 for example configurations). 

• Using an oscilloscope to compare the CLK2 waveform with those in Figure 11-10. 



11.4 THERMAL CHARACTERISTICS 

The thermal specification for the 80386 defines the maximum case temperature. This section 
describes how to ensure that an 80386 system meets this specification. 

Thermal specifications for the 80386 are designed to guarantee a tolerable temperature at 
the surface of the 80386 chip. This temperature (called the junction temperature) can be 
determined from external measurements using the known thermal characteristics of the 
package. Two equations for calculating junction temperature are as follows: 

Tj = T, + {6,^ * PD) and 

Tj = T, + (^j, * PD) 
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where 
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TERMINATION RESISTOR (OHMS) 
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Cboard is calculated from layout and board PARAMETERS: 
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Figure 11-8. CLK2 Series Termination 



Tj = junction temperature 



= ambient temperature 



Tc = case tempterature 



6j^ = junction-to-ambient temperature coefficient 



^jc = junction-to-case temperature coefficient 



PD = power dissipation (worst-case lec * V^, 



11-8 



Intel 



PHYSICAL DESIGN AND DEBUGGING 




Figure 1 1-9. CLK2 Loading 



WAVEFORMS 
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Figure 11-10. CLK2 Waveforms 



Case temperature calculations offer several advantages over ambient temperature 
calculations: 



Case temperature is easier to measure accurately than ambient temperature because the 
measurement is localized to a single point (top center of the package). 

The worst-case junction temperature (Tj) is lower when calculated with case temperature 
for the following reasons: 

- The junction-to-case thermal coefficient (B-^J is lower than the junction-to-ambient 
thermal coefficient {S^J; therefore, calculated junction temperature varies less with 
power dissipation (PD). 

- ^jc is not affected by air flow in the system; ^j^ varies with air flow. 
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With the case-temperature specification, the designer can either set the ambient tempera- 
ture or use fans to control case temperature. Finned heat sinks or conductive cooling may 
also be used in environments where the use of fans is precluded. To approximate the case 
temperature for various environments, the two equations above should be combined by setting 
the junction temperature equal for both, resulting in this equation: 

The current data sheet should be consulted to determine the values of ^j^ (for the system's 
air flow) and ambient temperature that will yield the desired case temperature. Whatever 
the conditions are, the case temperature is easy to verify. 



1 1.5 DEBUGGING CONSIDERATIONS 

This section outlines an approach to building and debugging 80386 hardware incrementally. 
In a short time, a complete 80386-based system can be built and working. This approach 
does not have to be followed to the letter, but it provides several valuable debugging concepts 
and useful hints. Use these guidelines in conjunction with the 80386 data sheet, which contains 
detailed information about the 80386. 



1 1 .5. 1 Hardware Debugging Features 

Even before a system is built, debugging can be made easier by planning a suitable environ- 
ment for the 80386. The 80386 board (whether it is a printed circuit board or a wire-wrap 
board) must have power and ground planes. The user should provide a decoupling capacitor 
between V^c and GND next to each IC on the board. All 80386 V^c and GND pins should 
be connected individually to the appropriate power or ground plane; multiple power or ground 
pins should not be daisy-chained. 

Room in the system should be included for the following physical features to aid debugging: 

• Two switches: one for generating the RESET signal to the 80386 and one for tying the 
READY# signal high (negated). 

• Connections for a logic analyzer on major control signals: 

Inputs to the 80386: 
Ready (READY#) 
Next Address (NA#) 
BusSizel6(BS16#) 
Data Bus (D0-D31) 

Outputs from the 80386: 
Address Strobe (ADS#) 

Write/Read (W/R#), Data/Control (D/C#), 

Memory/IO (M/IO#), Lock (LOCK#) 
Address Bus (A2- A3 1) 
Byte Enable (BE0fBE3#) 
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Logic analyzer connection points should be provided to all 80386 address outputs 
(A2-A31 and BE0#-BE3#) even if there are not enough logic analyzer inputs to accom- 
modate all of them. Initially, only BEO#, BE1#, BE2#, BE3#, and the output of the address 
decoder circuit should be connected. The single output of an address decoder circuit 
represents many bits of address information. If the address decoder does not work as 
expected, more of the logic analyzer inputs should be moved to the 80386 address pins. 

• Buffers and visual indicators (such as LEDs) for three or four of the critical 80386 control 
signals. A visual indicator for the ADS# output, for example, will light when the system 
is performing bus cycles. 

11.5.2 Bus Interface 

During initial debugging, bus-cycle operation should be simplified. The 80386 bus interface 
is flexible enough to be tested in stages. To simplify bus control, the initial testing should be 
performed with a non-pipelined address. The NA# input should be tied high (negated) to 
guarantee no address pipelining. The only signals that need to be controlled are the READY# 
input and the BS16# input. 

The READY# input on the 80386 lets the user delay the end of any bus cycle for as long as 
necessary. For each CLK cycle after T2 that READY# is not sampled active, a wait state 
is added. READY# can be used to provide extra time (wait states) for slow memories or 
peripherals. Wait state requirements are a function of the device being addressed. Therefore, 
the address decoder must determine how many wait states, if any, to add to each bus cycle. 
The address decoder circuit (usually in conjunction with a shift register) must generate the 
READY# signal when it is time for the bus cycle to end. It is critical for the system to 
generate the READY# signal; if it does not, the 80386 will wait forever for the bus cycle to 
end. 

EPROMs, static RAMs, and peripherals all interface in much the same way. The EPROM 
interface is the simplest because EPROMs are read-only devices. RAM interfaces must 
support byte addressability during RAM write cycles. Therefore, RAM write enables for 
each byte of the 32-bit data bus must be controlled separately. 

The BS16# signal must be activated when the current bus cycle communicates over a 16-bit 
bus. An address decoder circuit can be used to determine if BS16# must be asserted during 
the current bus cycle. 

11.5.3 Simplest Diagnostic Program 

To start debugging 80386 hardware, the user should make a set of EPROMs containing a 
simple program, such as a 4-byte diagnostic that loops. Such a program is shown in 
Figure 11-11. Because the program is four bytes long, it will exercise all 32 bits of the data 
bus. This program tests only the code prefetch ability of the 80386. 

In generating this program, the user should take into account the initial values of the 
80386 CS register (FOOOH) and IP register (FFFOH) after reset. The software entry point 
(label START in Figure 11-11) must match the CS:IP location. 
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ASSUME CS:S IMPLEST_CODE 



0000 SIMPLEST_CODE SEGMENT 

FFFO ORG OFFFOH 



FFF0 90 START: NOP 

FFF1 90 NOP 

FFF2 EB FC JMP START 



FFF4 SIMPLEST_CODE ENDS 

END 



Figure 11-11. 4-Byte Diagnostic Program 

The 80386 is initially in Real Mode (the mode that emulates the 8086) after reset. With 
this simple diagnostic code, it will remain in Real Mode. In Real Mode, CS:IP generates 
the physical code fetch address directly, without any descriptors, by adding CS and IP in 
the following way: 

(CS) FOOO 

(IP) + FFFO 



FFFFO 



Also, after reset (until the 80386 executes an intersegment JMP or CALL instruction), the 
physical base address of the code segment is set internally to FFFFOOOOH. Therefore, the 
physical address of the first code fetch after reset is always FFFFFFFOH. The simple 
diagnostic program must begin at this location. 

1 1.5.4 Building and Debugging a System Incrementally 

When designing an 80386 system, the designer plans the entire system. The core portions 
must be tested, however, before building the entire system. Beginning with only the 80386 
and the 82384 Clock Generator, the following steps outline an approach that enables the 
designer to build up a system incrementally: 

1. Install the 82384 and its crystal. Check that the CLK2 signal is clean. Connect the CLK2 
signal to the 80386. 

2. Connect the 82384 RESET output to the 80386 RESET input, and with CLK2 running, 
check that the state of the 80386 during RESET is correct. 
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3. Tie the 80386 INTR, NMI, and HOLD input pins low. Tie the READY# pin high so 
that the first bus cycle will not end. Reset the 80386, and check that the 80386 is emitting 
the correct signals to perform its first code fetch from physical address FFFFFFFOH. 
Connect the address latch, and verify that the address is driven at its outputs. 

4. Connect the address decoding hardware to the 80386, and check that after reset, the 
80386 is attempting to select the EPROM devices in which the initial code to be executed 
will be stored. 

5. Connect the data transceiver to the system, and check that after reset, the transceiver 
control pins are being driven for a read cycle. Connect all address pins of the EPROM 
sockets, and check that after reset, they are receiving the correct address for the first code 
fetch cycle. 

Intel's iPPS programmer for EPROMs supports dividing an object module into four 
EPROMs, as is necessary for a 32-bit data bus to EPROM. The programmer can also divide 
an object module into two EPROMs for a 1 6-bit data bus to the EPROMs. (In this case, 
the BS16# input to the 80386 must be asserted during all bus cycles communicating with 
the EPROMs). 

When the 82384, crystal, 80386, address decoder, address latch, data transceiver, and 
READY# generation logic (including wait-state generation) are functioning, the 80386 is 
capable of running the software in the EPROMs. Now the simple debug program described 
above can be run to see whether the parts of the system work together. 

After installing the EPROMs, the READY# line should be tied high (negated) so that the 
80386 begins its first bus cycle after reset and then continues to add wait states. While the 
system is in this state, the circuit should be probed to verify signal states, using a voltmeter 
or oscilloscope probe. 

The programmer should check whether the address latches have latched the first address 
and whether the address decoder is applying a chip-select signal to the EPROMs. The 
EPROMs should be emitting the first four opcode bytes of the first code to be executed 
(90H, 90H, EBH, FCH for the 4-byte program of Figure 11-11), and the opcode should be 
propagating through the data transceivers to the 80386 data pins. 

Then the READY# input should be connected to the READY# generation logic, the 80386, 
and the results should be tested when the simple program runs. Because the program loops 
back on itself, it runs continuously. At this point, the system has progressed to running 
multiple bus cycles, so a logic analyzer is needed to observe the dynamic behavior of the 
system. 

When the EPROMs programmed with the simple 4-byte diagnostic program are installed 
and the 80386 is executing the code, the LED indicator for ADS# (if included in the system) 
glows, because ADS# is generated for each bus cycle by the 80386. It is necessary to check 
that the EPROMs are selected for each code fetch cycle. After system operation is verified 
with the simple program, more complex programs can be run. 



11-13 



Intel 



PHYSICAL DESIGN AND DEBUGGING 



11. 5.5 Other Simple Diagnostic Software 

Other simple programs can be used to check the other operations the system must perform. 
The program described here is longer than the 4-byte program illustrated previously; it tests 
the abilities to write data into RAM and read the data back to the 80386. 

This second diagnostic program, shown in Figure 11-12, is also suitable for placing into 
EPROMS. Because this diagnostic loops back to itself, the ADS# LED should glow contin- 
uously, just as it does when running the 4-byte program. 

The program in Figure 11-12 is based on the assumption that hardware exists to report 
whether the data being read back from RAM is correct. This hardware consists of a writable 
output latch that can display a byte value written to it. The byte value written is a function 
of the RAM data comparison test. If the data is correct, the byte value written is AAH 
(10101010); if the data is incorrect, 55H (01010101) is written. 

This diagnostic program is not comprehensive, but it does exercise EPROM, RAM, and an 
output latch to verify that the basic hardware works. 

The program is short (45 bytes) to be easily understood. Because it is short and because it 
loops continuously, a logic analyzer or even an oscilloscope can be used to observe system 
activity. 

This program can be written in ASM86 assembly language. Because the primary purpose of 
this program is to exercise the system hardware quickly, the 80386 is not tested extensively, 
and Protected Mode is not enabled. 

The diagnostic software verifies the ability of the system to perform bus cycles. The 80386 
fetches code from the EPROMs, implying that EPROM read cycles function correctly. 
Instructions in the program explicitly generate bus cycles to write and read RAM. The data 
value read back from RAM is checked for correctness, then a byte (AAH if the data is 
correct, 55H if it is not) is output to the 8-bit output latch. The program then loops back to 
its beginning and starts over. 

After the source code is assembled, the resulting object code should be as shown in 
Figure 11-13. 



11.5.6 Debugging Hints 

The debugging approach described in this section is incremental; it lets the programmer 
debug the system piece by piece. If even the simple 4-byte program does not run, a logic 
analyzer can be used to determine where the problem is. At the very least, the 80386 should 
be initiating a code fetch cycle to EPROM. 
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PAGE 


66,132 




; EQUATES 








LATCH 


EQU 


0C8H 


; PRESUMES A HARDWARE 

; LATCH IS AT I/O ADDR C8H 


GOOD SIGNAL 


EQU 


OAAH 




BAD_SIGNAL 


EQU 


055H 




; CODE TO 


VERIFY 


ABILITY TO WRITE 


AND READ RAM CORRECTLY 




ASSUME 


CS: INITIAL CODE 




INITIAL_CODE 


SEGMENT 






ORG 


OFOOOH 


;THIS IS INTENDED TO BE LOCATED 
;AT PHYSICAL ADDRESS FFFFFOOOH 


TST_LOOP: 


MOV 


BX, OOOOH 


; INITIALIZE BASE REGISTER TO 




MOV 


DS, BX 


; INITIALIZE DS REGISTER TO 




MOV 


[BX] , 5473H 


? WRITE 5473H TO RAM ADDR AND 1 




MOV 


[BX]+2, 2961H 


;WRITE 2961H TO RAM ADDR 2 AND 3 




JMP 


READ 


;JMP TO FORCE CPU TO BREAK 
;PRE-FETCH QUEUE AND FETCH THE 
;NEXT INSTRUCTION AGAIN. THIS 
; PREVENTS THE RAM DATA WRITTEN 
;FROM JUST LINGERING ON THE DATA 
;BUS UNTIL THE READ OCCURS 


READ: 


CMP 


[BX] , 5473H 


;READ DATA FROM RAM ADDR AND 1 
;AND COMPARE WITH VALUE WRITTEN 




JNE 


BADRAM 


;IF DATA DOESN'T MATCH, THEN JMP 




CMP 


[BX]+2, 2961H 


;READ DATA FROM RAM ADDR 2 AND 3 
yAND COMPARE WITH VALUE VJRITTEN 




JNE 


BADRAM 


;IF DATA DOESN'T MATCH, THEN JMP 




MOV 


AL, GOOD SIGNAL 






OUT 


LATCH, AL 


/•SIGNAL THAT DATA WAS CORRECT 




JMP 


TST__LOOP 




BADRAM: 


MOV 


AL, BAD SIGNAL 






OUT 


LATCH, AL 


; SIGNAL THAT DATA WAS BAD 




JMP 


TST_LOOP 






ORG 


OFFFOH 


/•POSITION THE FOLLOWING INSTRUCTION 
?AT OFFSET OFFFOH 


START : 


JMP 


TST_LOOP 


;INTRA-SEGMENT JUMP (WITHIN 

/•SEGMENT) 

/•THIS IS INTENDED TO BE THE FIRST 

INSTRUCTION EXECUTED, SO IT MUST 

?BE LOCATED AT PHYSICAL ADDRESS 

/•FFFFFFFOH. 


rNITIAL_CODE 


ENDS 
END 







Figure 11-12. More Complex Diagnostic Program 
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PAGE 



EQUATES 



66,132 



= 00C8 
= OOAA 
= 0055 



LATCH 

GOOD__SIGNAL 
BAD SIGNAL 



EQU 0C8H 
EQU OAAH 
EQU 055H 



CODE TO VERIFY ABILITY TO WRITE 
AND READ RAM CORRECTLY 













ASSUME 


CS: INITIAL CODE 


0000 








INITIAL_CODE 


SEGMENT 




FOOO 










ORG 


OFOOOH 


FOOO 
F003 
F005 
F009 
FOOE 


BB 
8E 
C7 
C7 
EB 


0000 

DB 

07 5473 

47 02 2961 

01 90 


TST_LOOP: 


MOV 
MOV 
MOV 
MOV 
JMP 


BX, OOOOH 
DS, BX 
[BX] , 5473H 
[BX]+2, 2961H 
READ 


FOll 
F015 
F017 
FOIC 


81 
75 
81 
75 


3F 
OD 
7F 
06 


5473 
02 2961 


READ: 


CMP 

JNE 
CMP 
JNE 


[BX] , 5473H 
BADRAM 

[BX]+2, 2961H 
BADRAM 


FOIE 
F020 
F022 


BO 
E6 

EB 


AA 
C8 
DC 






MOV 
OUT 
JMP 


AL, GOOD SIGNAL 
LATCH, AL 
TST_LOOP 


F024 
F026 
F028 


BO 
E6 
EB 


55 
C8 
D6 




BADRAM: 


MOV 
OUT 
JMP 


AL, BAD SIGNAL 
LATCH, AL 
TST_LOOP 


FFFO 
FFFO 


E9 


FOOO R 


START: 


ORG 
JMP 


OFFFOH 
TST_LOOP 


FFF3 








INITIAL_CODE 


ENDS 
END 





VJarning Severe 
Errors Errors 




Figure 1 1-13. Object Code for Diagnostic Program 
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The 80386 stops running only for one of three reasons: 

• The READY# signal is never asserted to terminate the bus cycle. 

• The HALT instruction is encountered, so the 80386 enters a HALT state. 

• The 80386 encounters a shutdown condition. In Real Mode operation (as in the simple 
diagnostic program), a shutdown usually indicates that the 80386 is reading garbage on 
the data bus. 

If the 80386 stops running, the cause can be determined easily if the system contains simple 
hardware decoders with associated LEDs to visually indicate halt and shutdown conditions. 
The 80386 emits specific codes on its W/R#, D/C#, M/IO#, and address outputs to indicate 
halt or shutdown. A circuit to decode these signals can be tested by executing a HLT 
instruction (F4H) to see if the halt LED is turned on. The shutdown LED cannot be tested 
in the same way, but its decoder is so similar to the halt decoder that if the halt decoder 
works, the shutdown decoder should also work. 

If the shutdown LED comes on and the 80386 stops running, the data being read in during 
code fetch cycles is garbled. The programmer should check the EPROM contents, the wiring 
of the address path and data path, and the data transceivers. The 4-byte diagnostic program 
should be used to investigate the system. This program should work before more complex 
software is used. 

If neither the halt LED nor the shutdown LED is on when the 80386 stops running, the 
READY# generation circuit has not activated READY# to complete the bus cycle. The 
80386 is adding wait states to the cycle, waiting for the READY# signal to go active. The 
address at the address latch outputs and the states of the W/R#, D/C#, and M/IO# signals 
should be checked to narrow the investigation to a specific part of the READY# generation 
circuit. Then the circuit should be investigated with the logic analyzer. 

Once the basic system is built and debugged, more software and further enhancements can 
be added to the system. The incremental approach described applies to these additions. 
Systematic, step-by-step testing and debugging is the surest way to build are liable 
80386-based system. 
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CHAPTER 12 
TEST CAPABILITIES 



The 80386 contains built-in features that enhance its testability. These features are derived 
from signature analysis, and proprietary test techniques. All the regular logic blocks of the 
80386, or about half of all its internal devices, can be tested using these built-in features. 

The 80386 testability features include aids for both internal and board-level testing. This 
chapter describes these features. 



12.1 INTERNAL TESTS 

Allowances have been made for tw^o types of internal tests: automatic self-test and Transla- 
tion Lookaside Buffer (TLB) tests. The automatic self-test is controlled completely by the 
80386. The designer needs only to initiate the test and check the results. The TLB tests must 
be externally developed and applied. The 80386 provides an interface that makes this test 
development simple. 



12.1.1 Automatic Self-Test 

The 80386 can automatically verify the functionality of its three major Programmable Logic 
Arrays (PLAs) (the Entry Point, Control, and Test PLAs) and the contents of its Control 
ROM (CROM). The automatic self -test is initiated by setting the BUSY# input active during 
initialization (as described in Chapter 3). The test result is stored in the EAX register of the 
80386. 

The self-test progresses as follows (see Figure 12-1): 

1. Normal PLA or CROM inputs are disabled. 

2. A pseudo-random count sequence, generated by an internal Linear Feedback Shift 
register (LFSR), provides all possible combinations of PLA and CROM inputs. 

3. PLA and CROM outputs for each input combinations are directed to a parallel-load 
LFSR. 

4. Through the action of this LFSR, a signature of all output results is accumulated. 

5. After all input combinations have been sequenced, the final contents of the LFSR are 
XORed with a signature constant stored in the 80386. If the LFSR contents match the 
signature constant, the result will be all zeroes, indicating functional PLA and CROM. 

6. The result is loaded into the EAX register. 

The self-test provides 100-percent coverage of single-bit faults, which statistically comprise 
a high percentage of total faults. 
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CROM 
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L 


LFSR 






J 


1 SIGNATURE CONSTANT 1 
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Figure 12-1, 80386 Self-Test 

12.1.2 Translation Lookaside Buffer Tests 

The on-chip Page Descriptor Cache of the 80386 stores its data in the TLB. (Cache opera- 
tion is discussed fully in Chapter 7.) The linear- to-physical mapping values for the most 
recent memory accesses are stored in the TLB, thus allowing fast translation for subsequent 
accesses to those locations. The TLB consists of: 

• Content-addressable memory (CAM) — holds 32 linear addresses (Page Directory and 
Page Table fields only) and associated tag bits (used for data protection and cache 
implementation) 

• Random access memory (RAM) — holds the 32 physical addresses (upper 20 bits only) 
that correspond to the linear addresses in the CAM 

• Logic-implements the four-way cache and includes a 2-bit replacement pointer that 
determines to which of the four sets a new entry is directed during a write to the TLB. 

To translate a linear address to a physical address, the 83086 tries to match the Page 
Directory and Page Table fields of the linear address with an entry in the CAM. If a hit 
(a match) occurs, the corresponding 20 bits of physical address are retrieved from the RAM 
and added to the 12 bits of the Offset field of the linear address, creating a 32-bit physical 
address. If a miss (no match) occurs, the 80386 must bring the Page Directory and Page 
Table values into the TLB from memory. 
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The 80386 provides an interface through which to test the TLB. Two 32-bit test registers of 
the 80386 are used to write and read the contents of the TLB through the MOV TREG, reg 
and MOV reg, TREG instructions. An 80386 program can be used to generate test patterns 
which are applied to the TLB through automatic test machines or assembly language 
programs. 

The paging mechanism of the 80386 must be disabled during a test of the TLB. The internal 
response is therefore not identical to that of normal operation, but the main functionality of 
the TLB can be verified. 

Test register #6 is used as the command register for TLB accesses; test register #7 is used 
as the data register. Addresses and commands are written to the TLB through the command 
register. Data is read from or written to the TLB through the data register. 

The two test operations that may be performed on the TLB are: 

• Write the physical address contained in the data register and the Unear address and tag 
bits contained in the command register into a TLB location designed by the data register. 

• Look up a TLB entry using the linear address and tag bits contained in the command 
register. If a hit occurs, copy the corresponding physical address into the data register, 
and set the value of the hit/miss bit in the data register. If a miss occurs, clear the 
/hit/miss bit. In this case, the physical address in the data register is undefined. 

A command is initiated by writing to the command register. The command register has the 
format shown in Figure 12-2 (top). The two possible commands are distinguished by the 



5 4 



^m 



LINEAR ADDRESS 



TAG 



LOOKUP/ 
WRITE# 



COMMAND REGISTER 



n 12 


11 


5 


4 


3 


2 
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Va 








i 


^ 



PHYSICAL ADDRESS 



DATA REGISTER 



MIT/REPLACEMENT 

MISS POINTER 

OR 

REPLACEMENT BIT 
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Figure 12-2. TLB Test Registers 



12-3 



iny 



TEST CAPABILITIES 



state of bit in the command register. If bit = 1, a TLB lookup operation is performed. 
If bit = 0, a TLB write is performed. 

The tag bits (not including the linear address) consist of the following: 



Bit 


Name 


Definition 


11 

10 

9 

8 

7 

6 

5 


Valid (V) 

Dirty (D) 

Not Dirty (D#) 

User (U) 

Not User (U#) 

Writable (W) 

Not Writable (W#) 


Entry Is valid 

Entry has been changed 

Entry has not been changed 

Entry is accessible to User privilege level 

Entry Is not accessible to User privilege level 

Entry may be changed 

Entry may not be changed 



The complement of the Dirty, User, and Writable bits are provided to force a hit or miss for 
TLB lookups. A lookup operation with a bit and its complement both low is forced to be a 
miss; if both bits are high, a hit is forced. A write operation must always be performed with 
a bit and its complement bit having opposite values. 

The data register has the format shown in Figure 12-2 (bottom). The replacement pointer 
indicates which of the four sets of the TLB is to receive write data. Its value is changed 
according to a proprietary algorithm after every TLB hit. For testing, a TLB write may use 
the replacement pointer value that exists in the TLB, or it may use the value in bits 3 and 2 
of the data register. If data register bit 4 = 0, the existing replacement pointer is used. If 
bit 4 = 1 , bits 3 and 2 of the data register are used. 

The TLB write operation progresses as follows: 

1. The physical address, replacement bit, and replacement pointer value (optional) are written 
to the data register. 

2. The linear address and tag values are written to the command register, as well as a 
value for bit 0. 



It is important not to write the same linear address to more than one TLB 
Otherwise, hit information returned during a TLB lookup operation is undefined. 



entry. 



The TLB lookup operation progresses as follows: 

• The linear address and tag values are written to the command register, as well as a 
1 value for bit 0. 

• New values for the hit/miss bit and replacement pointer are written to bits 4-2 in the 
data register. If the hit/miss bit (bit 4) is 1, bits 31-12 contain the physical address from 
the TLB. Otherwise, bits 31-12 are undefined. 
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For more information on how to write routines to test the TLB, refer to the 
80386 Programmer's Reference Manual 

12.2 BOARD-LEVEL TESTS 

For board-level testing, it is often desirable to isolate areas of the board from the interactions 
of other devices. The 80386 can be forced to a state in which all but two of its pins are 
effectively removed from their circuits. This state is accomplished through the HOLD and 
HLDA pins. 

When the HOLD input of the 80386 is asserted, the 80386 places all of its outputs except 
for HLDA in the three-state condition. HLDA is then driven high. The 80386 remains in 
this condition until HOLD is de-asserted. Note that RESET being asserted takes priority 
over HOLD requests. 

The 80386 completes its current bus cycle before responding to the HOLD input. Detailed 
information on HOLD/HLDA response is given in Chapter 3. 
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APPENDIX A 
LOCAL BUS CONTROL PAL DESCRIPTIONS 



The bus controller is implemented in two PALs. One PAL (called PAL-1) follows the 80386 
bus cycles and generates the overall bus cycle timings. The second PAL (PAL-2) generates 
most of the bus control signals. 

The PALs are clocked by CLK2. They could also be clocked by CLK. Using CLK2 has the 
following advantages over using CLK: 

• The skew from clock to command signal is reduced, so higher performance is possible 
with slower devices. 

• The 80386 ADS# and READY# signals can be sampled directly. If CLK were used, it 
would be possible to sample ADSO# from the 82384 instead of ADS#, but the READY# 
generation logic would be more complex because READY# must be synchronized to 
CLK2. 

• The PAL can provide delays in 31 -nanosecond, rather than 62-nanosecond, increments. 
The advantages of using CLK to clock the PALs are as follows: 

• A slower PAL device could be used. 

• One PAL input is saved because only CLK, rather than CLK and CLK2, is needed. 

Because CLK2 is used to clock the PALs, the choice of PALs is currently limited to only 
20-pin B-series PALs. 

PAL-1 FUNCTIONS 

PAL-1 is implemented as two main state machines. The BUSSTATE state machine, which 
is used to follow the 80386 bus cycles, is specified by the state of two signals, IDLE and 
PIPE, and follows the 80386 bus by sampling ADS# and READY#. IDLE and PIPE are 
often useful in implementing other 80386 subsystems (such as the DRAM controller described 
later in this book). 

The LOCALSTATE state machine keeps track of the local bus state and is specified by 
signals L2, LI, and LO. Although the local bus state usually follows the 80386 bus state, so 
that the LOCALSTATE and BUSSTATE states are the same, there are times when the 
local bus cycle lags the 80386 bus cycle in order to handle data-float and peripheral recovery 
times correctly. Therefore, it is easier to implement this PAL using the two separate state 
machines. LOCALSTATE uses the 80386 W/R# signal and various chip-select inputs to 
determine what type of cycle to run. 

A third, simpler state machine is also implemented in PAL-1. Ql and QO comprise a 
SEQUENCE counter that is used to implement the various time delays required by the local 
bus state machine. 
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The NA# output of PAL-1 activates address pipelining for the I/O and 1 -wait-state devices. 
For 0-wait-state devices, external logic generates NA#, because these devices require NA# 
sooner than PAL-1 can generate it. 

PAL-2 FUNCTIONS 

PAL-2 generates most bus control signals, including all five command signals, the READY# 
signal, and the latch and transceiver enable signals. PAL-2 inputs the three LOCALSTATE 
signals from PAL-1 and the three 80386 bus cycle definition pins (MIO#, DC#, and WR#) 
in order to foUov^^ the local bus state. PAL-2 also inputs the 0-wait-state chip-select signal 
in order to set output signals quickly enough for zero wait states. 

Note that the transceiver direction enable (DT/R#) is simply a latched version of W/R#. 
This saves a PAL output and also guarantees that the transceiver direction does not change 
while DEN# is enabled. 

PAL EQUATIONS 

The equations for PAL-1 and PAL-2 are shown in Figures A-1 and A-2, respectively. These 
equations are shown in a high-level PAL language (ABEL, by Data I/O) that allows the 
PAL to be described as a series of states rather than equations. This language frees the 
designer of the tedious task of implementing the state machine and reducing the logical 
equations manually. The language saves time not only in the initial design, but also in 
debugging the state machines. The automated term reduction of the high-level PAL language 
allows the designer to explore many implementations quickly, which is a useful feature for 
complex PAL designs. 

Figures A-3 and A-4 show the PAL equations for PAL-1 and PAL-2 using PALASM by 
Monolithic Memories. 
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module Bus_ 


Control_386_Pal 


_1 flag '-r3' 


title 








'80386 Local Bus Controller - 


pal 1 Intel Corp' 


BC386P1 


device 'P16R8 


• ; "use a 16R8 B-speed PAL for 16MHz 386 


" Constants: 








ON 


= . 


1; 




OFF 


= 


0; 




H 


= 


i; 




L 


= 


0; 




X 


= 


.X. 7 


" ABEL 'don't care' symbol 


c 


= 


.C. ; 


" ABEL 'clocking input' symbol 


" state definitions 


for BUSSTATE (bus cycle state) : 


IDLEBUS 


= 


^bOl; 


"bus is idle or first CLK of unpipelined 


PIPEBUS 


= 


^blO; 


"first CLK of pipelined cycle 


ACTIVEBUS 


= 


^bOO; 


"subsequent CLKs of active bus 


IT.T.EGALBUS 


= 


-^bll; 


"unused 


" State definit 


ions 


for LOCALSTATE (local cycle state) : 


WAITING 


= 


^blOl; 


"waiting for next bus cycle 


SAMPLECS 


= 


^blOO; 


"CLK2 before ALE falls and CS is sampled 


CMDDELAY 


ss 


^bOOO; 


"delay before CMD active 


10 


= 


^bOlO; 


"10 CMD active 


ENDIO 


= 


-bllO; 


"10 CMD inactive 


MEMORY 


= 


^bOll; 


"IWS CMD active 


FLOAT 


= 


^blll; 


"data bus float delay 


NOTLOCAL 


= 


^bOOl; 


"OWS cycle or bus cycle not to the local bus 


" State definit 


ions 


for SEQUENCE (local cycle sequence counter) : 


SEQO 


- 


^bOO; 




SEQl 


= 


^bOl; 




SEQ2 


= 


^bll; 




SEQ3 


= 


^blO; 




" Pin names: 












II 


Input pins 


CLK 


pin 


2; 


" 82384 CLK 


ADS 


pin 


3; 


" 80386 ADS# 


READY 


pin 


4; 


" 80386 READY! 


WR 


pin 


5; 


" 80386 W/R# 


CSOWS 


pin 


6; 


" chip-select for wait-state (piped) devices 


CSIWS 


pin 


7; 


" chip-select for 1 wait-state (piped) devices 


CSIO 


pin 


8; 


" chip-select for peripheral devices 


RESET 


pin 


9; 


» 80386/82384 RESET 


CLK2 


pin 


1; " 


Clock pin - 82384 CLK2 


OE 


pin 


11; 


Output Enable pin 






•1 


Output pins 


NA 


pin 


19; 


" NEXT ADDRESS (NA) for IWS and 10 devices 


IDLE 


pin 


18; 


" bus state: IDLE or first CLK of unpiped cycle 


PIPE 


pin 


17; 


" bus state: first CLK of pipelined cycle 


L2 


pin 


16; 


" local cycle state 


LI 


pin 


15; 


" local cycle state 


LO 


pin 


14; 


" local cycle state 


Ql 


pin 


13; 


" local cycle sequence counter 


QO 


pin 


12; 


" local cycle sequence counter 


BUSSTATE 


= 


[PIPE, IDLE]; " bus cycle state | 


LOCALSTATE 


= 


[L2, LI 


LO]; " local cycle state 


SEQUENCE 




[Ql, QO]; " local cycle sequence counter 



Figure A-1. PAL-1 State Listings 
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COUNTING macro 

{ (Ql # QO) ); " true until sequencer counts down to zero 

LOWCOUNTING macro 

( ( QO) } ; " true until sequencer counts down to zero 

" same as COUNTING except used to reduce PAL 
" teritis and only works if count less than 3 

M II It II II II II II II II II II II II II II II II II II II II II II II II If II II 11 II II II 11 II II II II II II II II II II II II II II II fl H II II II II If II II II II II II II II II II II II II II II II II II 



state_diagram BUSSTATE 

state IDLEBUS: "bus is idle or first CLK of unpipelined 

if RESET then IDLEBUS "reset to IDLEBUS 

else if !CLK # ADS then IDLEBUS "remain til sample ADS active 
else ACTIVEBUS; "...then go ACTIVE 

state ACTIVEBUS: "subsequent CLKs of active bus 

if RESET then IDLEBUS "reset to IDLEBUS 

else if !CLK # READY then ACTIVEBUS "remain til sample READY active 
else if IADS then PIPEBUS "...then next cycle either piped 
else IDLEBUS; "...or idle 



state PIPEBUS: 

if RESET then IDLEBUS 

else if !CLK then PIPEBUS 

else ACTIVEBUS; 

state ILLEGALBUS: 
goto IDLEBUS; 



"first CLK of pipelined cycle 
"reset to IDLEBUS 
"remain for just one CLK 
"... then go ACTIVE 

"unused state - should never occur 
"if entered upon power-up ... go IDLE 



II II II 11 II II II II II II II If II It II If II II II II II If II II II II II II II II II II II II II II If If If II II II II II II II II II 11 II II II II II II II II II II II II II If 11 II n II II II II II II II II II II II II II 



state_diagram LOCALSTATE 

state WAITING: 
NA := OFF; 
if RESET then WAITING 
else if iCLK 

#( ADS & IDLE) 

#( ICSIO & LOWCOUNTING) then 
else 

state SAMPLECS: 
NA := OFF; 
if RESET then WAITING 

else if ICSIWS then MEMORY 
else if !CSIO then CMDDELAY 
else NOTLOCAL; 



"waiting for next bus cycle 

"reset to WAITING 

"remain while idle bus 
WAITING " . . and remain for recovery time 
SAMPLECS;". .else begin bus cycle 

"CLK2 before ALE falls and CS is sampled 

"reset to WAITING 
"start IWS access 
"start 10 access 
"start non-local access 



state CMDDELAY: 
NA := OFF; 
if RESET then WAITING 
else 10; 

state 10: 

NA := (I COUNTING & CLK) # NA; 
if RESET then WAITING 
else if INA then 10 

else ENDIO; 



"delay before CMD active 

"reset to WAITING 

"only in state for 1 CLK2, then 10 

"10 CMD active 

"activate NA after count down to zero 
"reset to WAITING 
"remain until NA active 
"... then ENDIO 



state ENDIO: 
NA := OFF; 
if RESET then WAITING 
else if LOWCOUNTING then ENDIO 
else FLOAT; 



"10 CMD active 

"reset to WAITING 

"remain while COUNTING down 

"... then FLOAT 



Figure A-1. PAL-1 State Listings (Cont'd.) 
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state MEMORY: 


"IWS CMD active 


NA := (!NA & CLK) # (NA & !CLK); 


"activate NA on second and third CLK2 


if RESET then WAITING 


"reset to WAITING 


else if LOWCOUNTING then MEMORY 


"remain while COUNTING down 


else FLOAT; 


"... then FLOAT 


state FLOAT: 


"data bus float delay 


NA := OFF; 




if RESET then WAITING 


"reset to WAITING 


else if "IDLE & !CLK & CSOWS & CSIWS & CSIO then NOTLOCAL | 




"watch for non-local bus cycle to start 


else if COUNTING then FLOAT 


"...else remain while COUNTING down 


else WAITING; 


"...then WAIT 


state NOTLOCAL: "OWS 


cycle or bus cycle not to the local bus 


NA := OFF; 




if RESET then WAITING 


"reset to WAITING 


else if READY # I CLK then NOTLOCAL "remain until bus cycle ends | 


else if COUNTING then FLOAT 


"...then finish FLOAT if still COUNTING 


else if IADS then SAMPLECS 


"...else SAMPLECS if next bus piped 


else WAITING; 


"...else WAIT 


tl II II II II II M II II II II II II II II II II II II M II 11 II II II II II II (1 II II II II II II H II II II II II II II II II II II II 11 II II II II II II II II II 11 II II II II II II 11 II II II II II II tl II II II II II II 


state_diagraiti SEQUENCE "counter for LOCALSTATE 


state SEQ3: 




if RESET then SEQO 


"reset to SEQuence 


else if !CLK then SEQ3 


"no change if CLK low 


else SEQ2; 


"count down every time CLK high 


state SEQ2: 




if RESET then SEQO 




else if ICLK then SEQ2 




else SEQl; 




state SEQl: 




if RESET then SEQO 




else if iCLK then SEQl 




else SEQO; 




state SEQO: "once count all the way 


down, figure out what to count next 


case 




RESET 


• 


SEQO; "reset to SEQuence 


! RESET & (LOCALSTATE == WAITING) 




SEQO; "count not used 


! RESET & (LOCALSTATE == SAMPLECS) 


& ! CSIWS 


SEQ2; "set up for IWS MEMORY 


1 RESET & (LOCALSTATE == SAMPLECS) 


& CSIWS 


SEQO; "other than IWS MEMORY 


•RESET & (LOCALSTATE == CMDDELAY) 


& WR 


SEQ3; "set up for 10 write 


1 RESET & (LOCALSTATE == CMDDELAY) 


& !WR 


SEQ2; "set up for 10 read 


! RESET & (LOCALSTATE == 10) 


& !NA 


SEQO; "still in 10... remain 


1 RESET & (LOCALSTATE == 10) 


& NA 


SEQl; "set up for ENDIO 


"RESET & (LOCALSTATE == ENDIO) 




SEQ3; "set up for 10 float 


1 RESET & (LOCALSTATE == MEMORY) 




SEQl; "set up for IWS MEMORY 


1 RESET & (LOCALSTATE == FLOAT) 




. SEQl; "set up for 10 recovery 


! RESET & (LOCALSTATE == NOTLOCAL) 




: SEQO; "count not used 


endcase; 





Figure A-1. PAL-1 State Listings (Cont'd.) 
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II II II II 11 II II II II It II II II 11 II II II II II II II II II II II II II II II II II If II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II 11 II II II 


test_ 


vectors 




( [CLK2, CLK, RESET, 


ADS 


READY, WR, CSOWS, CSIWS, CSIO] 


-> 










[LOCALSTATE, NA] ) 












11 


"inputs] -> [outputs] 








"C C 


R 


A R 


W 


c c c 






N 






"L L 


E 


D E 


R 


s s s 






A 






"K K 


S 


S A 




oil 


LOCALSTATE 






"2 


E 
T 


D 
Y 




W W 

s s 












Cc,x 


H 


x,x 


X 


x,x,x. 


-> 


WAITING 


L] 


•"initialize to IDLE and WAITING 


state 


[c,L 


L 


H,H 


X 


x,x 


X 


-> 


WAITING 


L] 






[c,H 


L 


H,H 


X 


x,x 


X. 


-> 


WAITING 


L] 






[c,L 


L 


x,H 


X 


X,x 


X 


-> 


WAITING 


L] 






[c,H 


L 


L,H 


X 


x,x 


X 


-> 


SAMPLECS 


L] 


"'lOOnS SRAM read 




[c,L 


L 


x,H 


L 


L,H 


H 


-> 


NOTLOCAL 


L] 


•"NA: activated externally 




[C,H 


L 


H,H 


X 


x,x 


X 


-> 


NOTLOCAL 


r L] 






[c,L 


L 


x,L 


X 


x,x 


X 


-> 


NOTLOCAL 


L] 






[c,H 


L 


L,L 


X 


x,x 


X 


-> 


SAMPLECS 


L] 


•"lOOnS SRAM read 




[c,L 


L 


X,H 


L 


L,H 


H 


-> 


NOTLOCAL 


L] 


•"NA: activated externally 




[c,H 


L 


H,H 


X 


x,x 


X 


-> 


NOTLOCAL 


f L] 






[c,L 


L 


X,L 


X 


x,x 


X 


-> 


NOTLOCAL 


. L] 






[C,H 


L 


L,L 


X 


x,x 


X 


-> 


SAMPLECS 


r L] 


•"lOOnS SRAM write 




Cc,L 


L 


X,H 


H 


L,H 


H 


-> 


NOTLOCAL 


. L] 


?"NA: activated externally 




[c,H 


L 


H,H 


X 


x,x 


X 


-> 


NOTLOCAL 


r L] 


• 




[c,L 


L 


X,H 


X 


, x,x 


rX 


-> 


NOTLOCAL 


f L] 


• 




[C,H 


L 


X,H 


X 


x,x 


X 


-> 


NOTLOCAL 


r L] 


• 




[c,L 


L 


x,L 


X 


, x,x 


rX 


-> 


NOTLOCAL 


f L] 






[C,H 


L 


L,L 


X 


r X,X 


rX 


-> 


SAMPLECS 


f L] 


;"100nS SRAM read 




[C,L 


L 


X,H 


L 


L,H 


H 


-> 


NOTLOCAL 


. L] 


•"NA: activated externally 




[c,H 


L 


r H,H 


f X 


r X,X 


rX 


-> 


'NOTLOCAL 


r L] 






[c,L 


L 


X,L 


X 


r X,X 


X 


-> 


NOTLOCAL 


f L] 






[C,H 


L 


L,L 


X 


r X,X 


pX 


-> 


SAMPLECS 


r L] 


• "non-local 




[c,L 


L 


X,H 


X 


, H,H 


pH 


-> 


NOTLOCAL 


r L] 






[c,H 


L 


H,H 


X 


f x,x 


rX 


-> 


■NOTLOCAL 


f L] 






[c,L 


L 


x,L 


X 


r X,X 


rX 


-> 


NOTLOCAL 


f L] 






[C;H 


L 


L,L 


X 


F X,X 


X 


-> 


SAMPLECS 


f L] 


■"lOOnS SRAM read 




[c,L 


L 


x,H 


X 


, L,H 


H 


-> 


NOTLOCAL 


r L] 


•"NA: activated externally 




[c,H 


L 


H,H 


X 


x,x 


X 


-> 


NOTLOCAL 


L] 


• 




[C,L 


L 


H,L 


X 


x,x 


X 


-> 


NOTLOCAL 


F L] 






[C/H 


L 


H,L 


X 


x,x 


X 


-> 


WAITING 


r L] 


•"idle 




[c,L 


L 


H,H 


X 


x,x 


X 


-> 


WAITING 


L] 






[c,H 


L 


H,H 


X 


x,x 


X 


-> 


WAITING 


L] 






[C,L 


L 


X,H 


X 


x,x 


X 


-> 


WAITING 


L] 






[C,H, 


L 


L,H 


X 


x,x 


X 


-> 


SAMPLECS 


L] 


"lOOnS SRAM write 




[C,L 


L 


x,H 


H 


L,H 


H 


-> 1 


NOTLOCAL, 


L]i 


"NA: activated externally 




[c,H 


L 


H,H 


X 


x,x 


X 


-> 


NOTLOCAL, 


L] 






[C,L 


L 


X,H 


X 


r X,X 


X 


-> 


NOTLOCAL 


L] 






[c,H 


L 


H,H 


X 


r X,X 


X 


-> 


NOTLOCAL, 


L] 






[C,L 


L 


r X,L 


X 


r X,X 


X 


-> 


NOTLOCAL 


L] 






[c,H 


L 


H,L 


X 


p x,x 


pX 


-> 


WAITING 


L] 


"idle 




[c,L 


L 


r H,H 


X 


r X,X 


X 


-> 


WAITING 


L] 






[C,H 


L 


f H,H 


X 


r X,X 


,x 


-> 


WAITING 


L] 






[c,L 


L 


r X,H 


r X 


, X,X 


fX 


-> 


WAITING 


L] 






[C,H 


L 


r L,H 


F X 


r X,X 


fX 


-> 


SAMPLECS 


L] 


"150nS ROM read 




[c,L 


L 


, X,H 


r L 


, H,L 


rH 


-> 


MEMORY 


L] 






[C,H 


L 


f H,H 


X 


r X,X 


pX 


-> 


MEMORY 


H] 






[c,L 


L 


, H,H 


f X 


r X,X 


fX 


-> 


MEMORY 


H] 






[c,H 


L 


r H,H 


r X 


t x,x 


,x 


-> 


MEMORY 


r L] 


■ 




[c,L 


L 


r X,L 


r X 


r X,X 


rX 


-> 


FLOAT 


. L] 


• 




[c,H 


L 


r L,L 


f X 


r X,X 


fX 


-> 


FLOAT 


f L] 






[c,L 


L 


f x,H 


r X 


r L,X 


fX 


-> 


WAITING 


r L] 






[c,H 


r L 


f H,H 


f X 


r X,X 


,H 


-> 


■SAMPLECS 


f L] 


•"lOOnS SRAM read 




[c,L 


L 


, X,H 


r L 


r L,H 


rH 


-> 


■NOTLOCAL 


r L] 


•"NA: activated externally 




[c,H 


L 


, x,H 


t X 


f x,x 


fX 


-> 


•NOTLOCAL 


r L] 


• 





Figure A-1. PAL-1 State Listings (Cont'd.) 
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LOCAL BUS CONTROL PAL DESCRIPTIONS 



[c,L, 


L, 


x,L, 


X, 


x,x,x; 


-> [1 


[c,H, 


L, 


L,L, 


X, 


x,x,x 


-> [£ 


[c,L, 


L, 


x,H, 


L, 


h,l,h: 


-> [ 


[c,H, 


L, 


H,H, 


X, 


x,x,x: 


-> [ 


[c,L, 


L, 


H,H, 


X, 


x,x,x; 


-> [ 


tc,H, 


L/ 


H,H, 


X, 


x,x,x: 


-> c 


[c,L, 


L, 


x,L, 


X, 


x,x,x; 


-> [ 


[c,H 


L, 


L,L, 


X 


x,x,x 


-> [ 


[c,L, 


L, 


X,H, 


X 


x,L,x 


-> [ 


[C,H 


L, 


H,H, 


X 


x,x,H 


-> [' 


[c,L 


L, 


H,H, 


H 


h,l,h: 


-> [ 


[C,H 


L, 


H,H 


X 


x,x,x; 


-> [ 


[c,L 


L, 


H,H, 


X 


x,>c,x] 


-> [ 


[c,H 


L, 


H,H 


X 


x,x,x: 


-> [ 


[c,L 


L, 


x,L 


X 


x,x,x; 


-> [ 


[c,H 


Li 


L,L 


X 


X/X,x: 


-> [ 


[c,L 


L 


X,H 


X 


x,L,x 


-> [ 


[c,H 


L 


H,H 


X 


x,x,H" 


-> [ 


[C,L 


L 


H,H 


L 


H,L,H 


-> c 


[c,H 


L 


H,H 


X 


x,x,x 


-> c 


[C,L 


L 


H,H 


X 


x,x,x 


-> c 


[c,H 


L 


H,H 


X 


r X,X,X 


-> [ 


[C,L 


L 


H,L 


X 


x,x,x 


-> [ 


[c,H 


r L 


H,L 


X 


, x,x,x 


-> [ 


[c,L 


L 


H,H 


X 


r X,X,X 


1 -> [ 


[c,H 


r L 


H,H 


r X 


, x,x,x 


1 -> [ 


[c,L 


r L 


x,H 


X 


r X,X,X 


] -> [ 


[c,H 


r L 


L,H 


r X 


, x,x,x 


] -> [ 


[c,L 


L 


x,H 


L 


, H,L,H 


-> [ 


[c,H 


L 


H,H 


X 


f x,x,x 


-> c 


[c,L 


L 


x,H 


X 


, x,x,x 


1 -> [ 


[c,H 


L 


L,H 


X 


, x,x,x 


1 -> [ 


[c,L 


, L 


L,L 


p X 


, x,x,x 


] -> c 


[C,H 


f L 


H,L 


r X 


, x,x,x 


] -> [ 


[C,L 


r L 


H,H 


X 


, x,x,x 


] -> [ 


[c,H 


, L 


H,H 


f X 


, x,x,x 


] -> [ 


rc,L 


, L 


r X,K 


r X 


, x,x,x 


] -> [ 


ic,H 


, L 


r L/H 


t X 


, x,x,x 


] -> c 


[c,L 


, L 


, X|H 


, L 


, H,H,L 


] -> [ 


[c,H 


, L 


, H,H 


, L 


, x,x,x 


] -> [ 


[C,L 


, L 


r H,H 


r X 


, x,x,x 


] -> [ 


[C,H 


, L 


r H,H 


, X 


, x,x,x 


] -> [ 


[c,L 


, L 


r H,H 


, X 


f x,x,x 


] -> [ 


[c,H 


, L 


r H,H 


, X 


, x,x,x 


] -> [ 


[c,L 


, L 


, H,H 


, X 


, x,x,x 


] -> [ 


[C,H 


, L 


r H,H 


, X 


, x,x,x 


] -> [ 


[c,L 


, L 


, H,H 


t X 


, x,x,x 


] -> [ 


[c,H 


, L 


H,H 


, X 


f x,x,x 


] -> [ 


[c,L 


r L 


, x,L 


r X 


, x,x,x 


] -> [ 


[C,H 


f L 


L,L 


f X 


, x,x,x 


] -> [ 


[c,L 


, L 


r X,H 


f X 


, x,x,L 


] -> [ 


[c,H 


L 


H,H 


F X 


, x,x,x 


] -> [ 


[c,L 


L 


H,H 


, X 


, x,x,L 


] -> [ 


[c,H 


L 


H,H 


r X 


, x,x,x 


] -> [ 


[c,L 


L 


H,H 


X 


, x,x,L 


] -> [ 


[c,H 


L 


H,H 


r X 


f x,x,L 


] -> [ 


[c,L 


L 


H,H 


r X 


, x,x,L 


] -> [ 


[c,H 


r L 


H,H 


X 


, x,x,x 


] "> [ 


[c,L 


, L 


H,H 


L 


, H,H,L 


] -> [ 


[C,H 


L 


H,H 


L 


, x,x,x 


] -> [ 


[c,L 


r L 


H,H 


X 


, x,x,x 


] -> [ 


[c,H 


L 


H,H 


X 


r X,X,X 


1 -> c 


[c,L 


L 


H,H 


X 


, x,x,x 


1 -> [ 


[c,H 


L 


H,H 


X 


r X,X,X 


"> [ 


[c,L 


r L 


H,H 


X 


, x,x,x 


] -> [ 



NOTLOCAL, 


L]; 


SAMPLECS , 


L];' 


MEMORY , 


L]; 


MEMORY , 


H]; 


MEMORY , 


H]; 


MEMORY , 


L]; 


FLOAT , 


L]; 


FLOAT , 


L]; 


WAITING, 


L]; 


SAMPLECS, 


L];' 


MEMORY , 


L]; 


MEMORY , 


H]; 


MEMORY , 


H]; 


MEMORY , 


L]? 


FLOAT , 


L]; 


FLOAT , 


L]- 


• WAITING 


L]? 


[SAMPLECS 


L]; 


: MEMORY 


L]; 


• MEMORY 


H]; 


[ MEMORY 


H]? 


MEMORY 


L]; 


FLOAT 


L]; 


FLOAT 


r L]; 


WAITING 


. L]; 


■ WAITING 


r L]; 


WAITING 


r L]; 


SAMPLECS 


r L]; 


• MEMORY 


f L]; 


■ MEMORY 


r H]; 


■ MEMORY 


, H]; 


[ MEMORY 


r L]; 


[ FLOAT 


, L]; 


[ FLOAT 


, L]; 


• WAITING 


, L]; 


[ WAITING 


, L]; 


[WAITING 


/ L]; 


"SAMPLECS 


. L]; 


■CMDDELAY 


, L]; 


[ 10 


, L]; 


10 


, L]; 


10 


, L]y 


10 


. L]; 


10 


/ L]? 


10 


. L]; 


10 


, H]; 


: ENDIO 


, H]; 


■ ENDIO 


, L]; 


■ FLOAT 


, L]; 


: FLOAT 


, L]; 


■ FLOAT 


, L]; 


' FLOAT 


, L]; 


• FLOAT 


, L]; 


■ FLOAT 


, L]; 


[WAITING 


/ L]; 


WAITING 


, L]; 


■WAITING 


, L]; 


SAMPLECS 


/ L]; 


: CMDDELAY 


/ L]; 


10 


. L]; 


10 


, L]; 


10 


/ L]7 


10 


, L]; 


10 


, L]; 


10 


, L]; 



'150nS ROM read 



"ISOnS SRAM write 



'150nS SRAM read 



"idle 



"150nS SRAM read 



"idle 



"peripheral read 



"peripheral read 



Figure A-1. PAL-1 State Listings (Cont'd.) 
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LOCAL BUS CONTROL PAL DESCRIPTIONS 



C,H 
c,L 
c,H 
c,L 
C,U 
c,L 
c,H 
c,L 
C,H 
C,L 
c,H 
C,L 
C,H 
C,L 
C,H 
c,L 
c,H 
c,L 
c,H 
c,L 
C,H 
c,L 
c,H 
c,L 
C,H 
c,L, 
c,H, 
c,L 



L, H,H 
L, H,H 
L, H,H 
L, X,L 
L, L,L 
L, x,H 
L, H,H 
L, H,H 
L, H,H 
L, H,H 
L, H,H 
L, H,H 
L, H,H 
L, X,L 
L, L,L 
L, x,H 
L, H,H 
L, H,H 
L, H,H 
L, H,H 
L, H,H 
L, H,H 
L, H,H 
L, H,H 
L, H,H 



x,L 



X, 


x,x,x] 


-> c 


X, 


x,x,x] 


-> c 


X, 


x,x,x] 


-> [ 


X, 


x,x,x] 


-> [ 


X, 


x,x,x] 


-> [ 


X, 


L,x,x] 


-> [ 


X, 


x,x,x' 


-> [ 


X, 


L,x,x: 


-> [ 


X, 


x,x,x" 


-> [ 


X, 


L,X,X" 


-> [1 


X, 


x,x,H- 


-> [ 


L, 


L,H,H] 


-> [] 


X, 


x,x,x: 


-> [] 


X, 


x,x,x; 


-> [] 


X, 


x,x,x] 


-> c 


H, 


H,H,L' 


-> [ 


H, 


x,x,x 


-> [ 


X, 


x,x,x 


-> [ 


X, 


x,x,x 


-> [ 


X, 


x,x,x 


-> c 


X, 


x,x,x 


I -> [ 


X, 


x,x,x 


-> [ 


X, 


x,x,x 


1 -> [ 


X, 


x,x,x 


1 -> [ 


X, 


x,x,x 


1 -> c 


Xf 


x,x,x 


] -> [ 


X, 


x,x,x 


] -> [ 


Xr 


x,x,x 


] -> c 


X, 


x,x,x 


] -> [ 



10 


Hi; 


ENDIO , 


H]; 


ENDIO 


LI? 


FLOAT , 


Li; 


FLOAT 


Ll; 


FLOAT 


Ll; 


FLOAT 


Ll; 


FLOAT 


Li; 


FLOAT 


Ll; 


WAITING 


Ll; 


SAMPLEGS 


Ll; 


NOTLOCAL, 


L]; 


NOTLOCAL, 


L]; 


NOTLOCAL, 


Ll; 


SAMPLEGS 


Ll; 


GMDDELAY, 


Ll; 


10 


L]; 


10 


L]; 


10 


L]; 


10 


L]; 


10 


L]; 


10 


Ll; 


10 


, L]; 


10 


, L]; 


10 


r H]; 


ENDIO 


, Hi; 


■ ENDIO 


, Ll; 


■ FLOAT 


, Ll; 


: FLOAT 


, L]; 



"lOOnS SRAM read 

"NA; activated externally 



'peripheral write 



end Bus Control 386 Pal 1; 



Figure A-1. PAL-1 State Listings (Cont'd.) 



A-8 



iny 



LOCAL BUS CONTROL PAL DESCRIPTIONS 



module Bus_Control_386_Pal_2 flag '-r3' 


title 








•80386 Local Bus Controller - 


pal 2 Intel Corp* 


BC386P2 


device ' P16R8 ' ; "use a 16R8 B-speed PAL for 16MHz 386 


" Constants : 








ON 


= 


1; 




OFF 


= 


0; 




H 


= 


1; 




L 


= 


0; 




X 


= 


.X. ; 


" ABEL 'don't care* symbol 


c 


= 


.C. ; 


" ABEL 'clocking input' symbol 


" state definitions for LOCALSTATE (local cycle state) : 


WAITING 


= 


^blOl; 


"waiting for next bus cycle 


SAMPLECS 


= 


^blOO; 


"CLK2 before ALE falls and CS is sampled 


CMDDELAY 


= 


^bOOO; 


"delay before CMD active 


10 


- 


^bOlO; 


"10 CMD active 


ENDIO 


= 


^bllO; 


"10 CMD inactive 


MEMORY 


= 


^bOll; 


"IWS CMD active 


FLOAT 


= 


^blll; 


"data bus float delay 


NOTLOCAL 


= 


^bOOl; 


"OWS cycle or bus cycle not to the local bus 


" Pin names: 












If 


Input pins 


CLK 


pin 


2; 


" 82384 CLK 


MIO 


pin 


3; 


" 80386 M/IO# 


DC 


pin 


4; 


" 80386 D/C# 


WR 


pin 


5; 


" 80386 W/R# 


LO 


pin 


6; 


" local cycle state (from PAL 1) 


LI 


pin 


7; 


" local cycle state (from PAL 1) 


L2 


pin 


8; 


" local cycle state (from PAL 1) 


CSOWS 


pin 


9; 


" chip-select for wait-state (piped) devices 


CLK2 


pin 


i; 


Clock pin - 82384 CLK2 


OE 


pin 


11; " 


Output Enable pin 






•1 


Output pins 


MRDC 


pin 


19; 


" Memory Read Control signal 


MWTC 


pin 


18; 


" Memory Write Control signal 


lORC 


pin 


17; 


" I/O Read Control signal 


I owe 


pin 


16; 


" I/O Write Control signal 


INTA 


pin 


15; 


" Interrupt Acknowledge Control signal 


ALE 


pin 


14; 


" Address Latch Enable Control signal 


DEN 


pin 


13; 


" Data Transceiver Enable Control signal 


RDY 


pin 


12; 


" READY signal 


LOCALSTATE 


= 


[L2, LI 


, LO]; " local cycle state 


" Macros: 








ifMEMORYREAD macro 




{ ( MIO 


& 


IWR) 


} ; " true for memory data or code read 


ifMEMORYWRITE macro 




{ ( MIO 


& DC 


& WR) 


} ; " true for memory data write 


iflOREAD macro 






{ (!MIO 


& DC 


& !WR) 


}; " true for I/O data read 


iflOWRITE macro 






{ (!MIO 


& DC 


& WR) 


} ; " true for I/O data write 


iflNTACK macro 






( (IMIO 


& !DC 


& !WR) 


} ; " true for interrupt acknowledge cycle 



Figure A-2. PAL-2 State Listings 
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LOCAL BUS CONTROL PAL DESCRIPTIONS 



II nil II II II II If II II 11 II II II II II tf II II II II II II II II II II II 11 II II II II II II II II II II II II II II II II 11 II II II II II II II II II II II II II II II II II If II II II II II II II II It II 


equations 






!MRDC := 






( (LOCALSTATE==WAITING) 


& OFF) 




# ( ( LOCALSTATE==SAMPLECS ) 


& itMEMORYREAD & !CSOWS) "activate if OWS access | 


# ( (LOCALSTATE==CMDDELAY) 


& OFF) 




# ( (LOCALSTATE==IO) 


& ((ifMEMORYREAD & DEN) # !MRDC) ) 


"activate if 10 


# ( (LOCALSTATE—ENDIO) 


& ((ifMEMORYREAD & DEN) # IMRDC) ) 


"remain if 10 


# ( (LOCALSTATE»=MEMORY) 


& ((ifMEMORYREAD & DEN) # IMRDC)) 


"activate IWS 


# ( (LOCALSTATE««FLOAT) 


& OFF) 




# ( (LOCALSTATE==NOTH)CAL) 


& (IMRDC & (RDY # ICLK))); 


"remain if OWS 


!MWTC := 






( (LOCALSTATE===WAITING) 


& OFF) 




# ( (LOCALSTATE==SAMPLECS) 


& ifMEMORYWRITE & ICSOWS) 




# ( (LOCALSTATE«=CMDDELAY) 


& OFF) 




# ( ( LOCALSTATE==IO ) 


& ((ifMEMORYWRITE & DEN) # (IMWTC & 


RDY) ) ) 


# ( (LOCALSTATE==ENDIO) 


& ((ifMEMORYWRITE & DEN) # (IMWTC & 


RDY) ) ) 


# ( (LOCALSTATE«=MEMORY) 


& ((ifMEMORYWRITE & DEN) # iMWTC) ) 




# ( (LOCALSTATE=«FLOAT) 


& OFF) 




# ( (LOCALSTATE»«NOTLOCAL) 


& (IMWTC & RDY)); 




IIORC := 






( (LOCALSTATE««WAITING) 


& OFF) 




# ( (LOCALSTATE«=SAMPLECS) 


& iflOREAD & ICSOWS) 




# ( (LOCALSTATE==CMDDELAY) 


& OFF) 




# ( (LOCALSTATE==IO) 


& ((iflOREAD & DEN) # lIORC)) 




# ( (LOCALSTATE=*=ENDIO) 


& ((iflOREAD & DEN) # IIORC)) 




# ( CLOCALSTATE-=MEMORY) 


& ((iflOREAD & DEN) # IIORC)) 




# ( (LOCALSTATE=-FLOAT) 


& OFF) 




# ( (LOCALSTATE»«NOTLOCAL) 


& (IIORC & (RDY # ICLK))); 




IIOWC := 






( (LOCALSTATE— WAITING) 


& OFF) 




# ( (LOCALSTATE=sfSAMPLECS) 


& iflOWRITE & ICSOWS) 




# ( (LOCALSTATE==CMDDELAY) 


& OFF) 




# ( (LOCALSTATE««IO) 


& ((iflOWRITE & DEN) # (IIOWC & 


RDY) ) ) 


# ( (LOCALSTATE«=ENDIO) 


& ((iflOWRITE & DEN) # (IIOWC & 


RDY) ) ) 


# ( (LOCALSTATE==MEMORY) 


& ((iflOWRITE & DEN) # IIOWC)) 




# ( (LOCALSTATE==FLOAT) 


& OFF) 




# ( (LOCALSTATE==NOTLOCAL) 


& (IIOWC & RDY)); 




IINTA := 






( (LOCALSTATE==WAITING) 


& OFF) 




# ( (LOCALSTATE==SAMPLECS) 


& iflNTACK & ICSOWS) 




# ( (LOCALSTATE==CMDDELAY) 


& OFF) 




# ( (LOCALSTATE-=«IO) 


& ((iflNTACK & DEN) # IINTA)) 




# ( (LOCALSTATE==ENDIO) 


& ((iflNTACK & DEN) # IINTA)) 




# ( (LOCALSTATE==MEMORY) 


& ((iflNTACK & DEN) # IINTA)) 




# ( (LOCALSTATE==FLOAT) 


& OFF) 




# ( (LOCALSTATE==NOTLOCAL) 


& (IINTA & (RDY # ICLK))) ; 




ALE : = 

( (LOCALSTATE==WAITING) 


& ON) "activate ALE while 


waiting 


# ( (LOCALSTATE==SAMPLECS) 


& OFF) 




# ( (LOCALSTATE==CMDDELAY) 


& OFF) 




# ( (LOCALSTATE«=«=IO) 


& OFF) 




# ( (LOCALSTATE==ENDIO) 


& OFF) 




# ( (LOCALSTATE==MEMORY) 


& OFF) 




# ( (LOCALSTATE==FLOAT) 


& OFF) 




# ( (LOCALSTATE==NOTLOCAL) 


& ( (DEN & CSOWS) "activate ALE if not-local 




# ALE "if active, . .remain active 




#(1RDY & CLK))); "activate if last CLK2 of OWS access 
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!DEN 














(( 


LOCALSTATE= 


==WAITING) 


& 


OFF) 




t((LOCALSTATE= 


==SAMPLECS ) 


& 


OFF) 




#((LOCALSTATE= 


==CMDDELAY) 


& 


OFF) 




#((LOCALSTATE= 


==I0) 




& 


ON) 


"activate DEN while in 10 


#((LOCALSTATE= 


==ENDIO) 


& 


ON) 


"activate DEN while in 10 


#((LOCALSTATE= 


==MEMORY) 


& 


ON) 


"activate DEN while in IWS access 


#((LOCALSTATE= 


==FLOAT) 


& 


(IMWTC # IIOWC)) "remain active 1 CLK2 if write 


#((LOCALSTATE= 


==NOTLOCAL) 


& 


( (!ALE & ICSOWS) "activate DEN if OWS access 












# IDEN) 


"if active. . .remain active 










& 


(RDY # !CLK)); "...until last CLK2 of OWS access 1 


•RDY 


• = 












((LOCALSTATE= 


==WAITING) 


& 


OFF) 




#((LOCALSTATE= 


==«SAMPLECS) 


& 


OFF) 




#(( 


LOCALSTATE^-CMDDELAY ) 


& 


OFF) 




#((LOCALSTATE= 


==I0) 




& 


OFF) 




#((LOCALSTATE= 


==ENDIO] 




& 


ON) 


"activate RDY at end of 10 


#((LOCALSTATE= 


==MEMORY) 


& 


((RDY & IDEN & CLK) # (!RDY & ICLK))) | 














"activate RDY at end of IWS access 


#((LOCALSTATE= 


==FLOAT 




& 


OFF) 




#((LOCALSTATE= 


==NOTLOCAL) 


& 


( ( RDY & 


CLK & ( (I MRDC # lIORC # • INTA) 














#((!MWTC # !IOWC) & IDEN))) 












#(IRDY & i 


CLK) ) ) ; 

"activate RDY at end of OWS access 


II II II II II II If II II II II II II II It II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II II 11 II II II II II II M 1 


test_ 


vectors 


( CCLK2, CLK, 


LOCALSTATE 


, MIO, DC, WR, CSOWS] -> 






[MRDC, MWTC, lORC, lOWC, INTA, ALE, DEN, RDY] ) 1 




"[inputs] - 


> [outputs] 




"C C 




M D W 


c 




M M I I I 


ADR 


"L L 




I C R 


s 




R W N 


LED 


"K K 


LOCALSTATE 










D T R W T 


E N Y 


"2 






w 

S 




C C C C A 




[c,L, 


X , 


x,x,x, 


X] 


-> 


[x,x,x,x,x. 


x,x,x] , 


"initialize to IDLE and WAITING 


[C,H, 


X , 


x,x,x, 


X] 


-> 


[x,x,x,x,x, 


x,x,x] , 




[c,L, 


X , 


x,x,x, 


X] 


-> 


[x,x,x,x,x, 


x,x,x], 




[C,H, 


^ 1 


x,x,x. 


X] 


-> 


[x,x,x,x,x, 


x,x,x]. 




[c,L, 


X , 


x,x,x, 


X] 


-> 


[x,x,x,x,x, 


x,x,x]. 




[c,H, 


X , 


X,XvX, 


X] 


-> 


[x,x,x,x,x, 


x,x,x] , 




[c,L, 


X , 


x,x,x, 


X] 


-> 


[x,x,x,x,x, 


x,x,x], 




Cc,H, 


X , 


x,x,x, 


X] 


-> 


[x,x,x,x,x, 


x,x,x] 




[C,L, 


WAITING, 


x,x,x, 


X] 


-> 


[H,H,H,H,H, 


H,H,H], 




[C,H, 


WAITING, 


x,x,x. 


X] 


-> 


[H,H,H,H,H, 


H,H,H], 




[c,L, 


WAITING, 


x,x,x. 


X] 


-> 


[H,H,H,H,H, 


H,H,H] 




[c,H, 


WAITING, 


x,x,x, 


X] 


-> 


[H,H, H,H,H, 


H,H,H] 


"lOOnS SRAM read 


CCL, 


SAMPLECS , 


H,L,L, 


L] 


-> 


[L,H,H,H,H, 


L,H,H]. 




[c,H, 


NOTLOCAL, 


x,x,x, 


L] 


-> 


[L,H,H,H,H, 


L,L,L] 




[c,L, 


NOTLOCAL, 


x,x,x. 


X] 


-> 


[L,H,H,H,H, 


L,L,L] 




[c,H, 


NOTLOCAL, 


x,x,x, 


X] 


-> 


[H,H,H,H,H, 


H,H,H] 


"lOOnS SRAM read 


[c,L, 


SAMPLECS , 


H,H,L, 


L] 


-> 


[L,H,H,H,H, 


L,H,H] 


• 


[c,H, 


NOTLOCAL, 


x,x,x. 


L] 


-> 


[L,H,H,H,H, 


L,L,L] 


• 


[c,L, 


NOTLOCAL, 


x,x,x, 


X] 


-> 


[L,H,H,H,H, 


L,L,L] 




[C,H, 


NOTLOCAL, 


x,x,x, 


X] 


-> 


[H,H,H,H,H, 


H,H,H] 


•"lOOnS SRAM write 


[c,L, 


SAMPLECS , 


H,H,H, 


L] 


-> 


[H,L,H,H,H, 


L,H,H] 




[c,H, 


NOTLOCAL, 


x,x,x. 


L] 


-> 


[H,L,H,H,H, 


L,L,H] 


; 


[C,L, 


NOTLOCAL, 


x,x,x, 


X] 


-> 


[H,L,H,H,H, 


L,L,H] 


? 
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NOTLOCAL 


x,x,x 


x; 


-> 


H,L,H,H,H, 


L,L,L] 


NOTLOCAL 


x,x,x 


X. 


-> 


H,H,H,H,H, 


L,L,L] 


NOTLOCAL 


x,x,x 


X 


-> 


H,H,H,H,H 


H,H,H] 


SAMPLE CS 


H,H,L 


L 


-> 


L,H,H,H,H, 


L,H,H] 


NOTLOCAL 


x,x,x 


L 


-> 


L,H,H,H,H 


L,L,L] 


NOTLOCAL 


x,x,x 


X 


-> 


L,H,H,H,H 


L,L,L] 


NOTLOCAL 


x,x,x 


X 


-> 


H,H,H,H,H 


H,H,H] 


SAMPLECS 


x,x/x 


H 


-> 


H,H,H,H,H 


L,H,H] 


NOTLOCAL 


x,x,x 


H 


-> 


H,H,H,H,H 


r H,H,H] 


NOTLOCAL 


x,x,x 


X 


-> 


H,H,H,H,H 


H,H,H] 


NOTLOCAL 


x,x,x 


X 


-> 


H,H,H,H,H 


H,H,H] 


SAMPLECS 


H,L,L 


L 


-> 


L,H,H,H,H 


f L,H,H] 


NOTLOCAL 


x,x,x 


L 


-> 


L,H,H,H,H 


L,L,L] 


NOTLOCAL 


x,x,x 


X 


-> 


L,H,H,H,H 


NOTLOCAL 


x,x,x 


X 


-> 


H,H,H,H,H 


f H,H,H] 


WAITING 


x,x,x 


X 


-> 


H,H,H,H,H 


H,H,H] 


WAITING 


x,x,x 


X 


-> 


H,H,H,H,H 


r H,H,H] 


WAITING 


x,x,x 


X 


-> 


H,H,H,H,H 


r H,H,H] 


WAITING 


x,x,x 


X 


-> 


H,H,H,H,H 


H,H,H] 


SAMPLECS 


H,H,H 


L 


-> 


H,L,H,H,H 


r L,H,H] 


NOTLOCAL 


x,x,x 


L 


-> 


H,L,H,H,H 


L,L,H] 


NOTLOCAL 


x,x,x 


X 


-> 


H,L,H,H,H 


L,L,H] 


NOTLOCAL 


x,x,x 


X 


-> 


H,L,H,H,H 


L,L,L] 


NOTLOCAL 


x,x,x 


X 


-> 


H,H,H,H,H 


L,L,L] 


NOTLOCAL 


x,x,x 


X. 


-> 


H,H,H,H,H, 


H,H,H] 


WAITING 


x,x,x 


X 


-> 


H,H,H,H,H, 


H,H,H] 


WAITING 


x,x,x 


X. 


-> 


H,H,H,H,H, 


H,H,H] 


WAITING 


x,x,x 


X 


-> 


H,H,H,H,H, 


H,H,H] 


WAITING 


x,x,x 


X 


-> 


H,H,H,H,H, 


H,H,H] 


SAMPLECS 


x,x,x 


h; 


-> 


H,H,H,H,H, 


L,H,H] 


MEMORY 


H,H,L 


X 


-> 


L,H,H,H,H 


L,L,H] 


MEMORY 


x,x,x 


X, 


-> 


L,H,H,H,H, 


L,L,H] 


MEMORY 


x,x,x 


x; 


-> 


L,H,H,H,H, 


L,L,L] 


MEMORY 


x,x,x 


X 


-> 


L,H,H,H,H, 


L,L,L] 


FLOAT 


x,x,x 


X 


-> 


H,H,H,H,H, 


L,H,H] 


FLOAT 


x,x,x 


X 


-> 


H,H,H,H,H, 


L,H,H] 


WAITING 


x,x,x 


X 


-> 


H,H,H,H,H 


H,H,H] 


SAMPLECS 


H,L,L 


L 


-> 


L,H,H,H,H 


L,H,H] 


NOTLOCAL 


x,x,x 


L 


-> 


L,H,H,H,H 


L,L,L] 


NOTLOCAL 


x,x,x 


X 


-> 


L,H,H,H,H 


L,L,L] 


NOTLOCAL 


x,x,x 


X 


-> 


H,H,H,H,H 


H,H,H] 


SAMPLECS 


x,x,x 


H 


-> 


H,H,H,H,H 


L,H,H] 


MEMORY 


H,L,L 


X 


-> 


■L,H,H/H,H 


L,L,H] 


MEMORY 


x,x,x 


X 


-> 


■L,H,H,H,H 


L,L,H3 


MEMORY 


x,x,x 


X 


-> 


•L,H,H,H,H 


L,L,L] 


MEMORY 


x,x,x 


X 


-> 


■L,H,H,H,H 


L,L,L] 


FLOAT 


x,x,x 


X 


-> 


•H,H,H,H,H 


L,H,H] 


FLOAT 


x,x,x 


r X 


-> 


rH,H,H,H,H 


L,H,H] 


WAITING 


x,x,x 


X 


-> 


H,H,H,H,H, 


H,H,H] 


SAMPLECS 


x,x,x 


H 


-> 


H,H,H,H,H, 


L,H,H] 


MEMORY 


H,H,H 


X 


-> 


H,L,H,H,H, 


L,L,H] 


MEMORY 


x,x,x 


X 


-> 


•H,L,H,H,H 


L,L,H] 


MEMORY 


x,x,x 


X 


-> 


•H,L,H,H,H, 


L,L,L] 


MEMORY 


x,x,x 


X 


-> 


■H,L,H,H,H 


L,L,L] 


FLOAT 


x,x,x 


X 


-> 


•H,H,H,H,H 


L,L,H] 


FLOAT 


x,x,x 


X 


-> 


'H,H,H,H,H, 


L,H,H] 


WAITING 


x,x,x 


X 


-> 


•H,H,H,H,H 


H,H,H3 


SAMPLECS 


x,x,x 


H 


-> 


'H,H,H,H,H 


L,H,H] 


MEMORY 


H,H,L 


X 


-> 


'L,H,H,H,H 


L,L,H] 


MEMORY 


x,x,x 


X 


-> 


:l,h,h,h,h 


L,L,H] 


MEMORY 


x,x,x 


X 


-> 


■L,H,H,H,H 


L,L,L] 


MEMORY 


x,x,x 


X 


-> 


:l,h,h,h,h 


L,L,L] 


FLOAT 


x,x,x 


X 


-> 


:h,h,h,h,h 


L,H,H] 


FLOAT 


x,x,x 


X 


-> 


'H,H,H,H,H 


L,H,H] 


WAITING 


x,x,x 


X 


~> 


'H,H,H,H,H 


H,H,H] 


WAITING 


r X,X,X 


, X 


1 -> 


H,H,H,H,H 


H,H,H] 


WAITING 


f x,x,x 


r X 


-> 


H,H,H,H,H 


H,H,H] 



"lOOnS SRAM read 

"non-local 

"READY: activated externally 

"lOOnS SRAM read 

"idle 

"lOOnS SRAM write 



"idle 



"150nS ROM read 



"lOOnS SRAM read 



"150nS ROM read 



"150nS SRAM write 



"150ns SRAM read 



"idle 



"150nS SRAM read 



Figure A-2. PAL-2 State Listings (Cont'd.) 
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[c,L 


SAMPLECS 


x,x,x 


h: 


-> i 


H,H,H,H,H 


L,H,H], 




[c,H 


MEMORY 


H,L,L 


f x; 


-> 


l,h,h,h,h 


L,L,H] 




[c,L 


MEMORY 


x,x,x 


X' 


-> 


L,H,H,H,H 


L,L,H] 




[c,H 


MEMORY 


x,x,x 


x; 


-> 


L,H,H,H,H 


L,L,L] 




[c,L 


MEMORY 


x,x,x 


X* 


-> 


L,H,H,H,H 


L,L,L] 




[c,H 


FLOAT 


x,x,x 


x; 


-> 


H,H,H,H,H 


L,H,H]i 




[C,L 


FLOAT 


x,x,x 


x; 


-> 


H,H,H,H,H 


L,H,H]i 


"idle 


[C/H 


WAITING 


x,x,x 


X 


-> 


H,H,H,H,H 


H,H,H]i 




[c,L 


WAITING 


x,x,x 


f X" 


-> 


H,H,H,H,H 


H,H,H]i 




Cc,H 


WAITING 


x,x,x 


X 


-> 


H,H,H,H,H 


H,H,H] 


"peripheral read 


[C,L 


SAMPLECS 


x,x,x 


H- 


-> 


H,H,H,H,H 


L,H,H], 




[c,H 


CMDDELAY 


x,x,x 


F X 


-> 


H,H,H,H,H 


L,H,H], 




[c,L 


10 


L,H,L 


f X 


-> 


H,H,L,H,H 


L,L,H]. 




[C,H 


10 


x,x,x 


X' 


-> 


H,H,L,H,H 


L,L,H], 




[C,L 


10 


x,x,x 


X 


-> 


H,H,L,H,H 


L,L,H]i 




[C,H 


10 


x,x,x 


X 


-> 


H,H,L,H,H 


L,L,H], 




[c,L 


10 


x,x,x 


X' 


-> 


H,H,L,H,H 


L,L,H] . 




[c,H 


10 


x,x,x 


X 


-> 


H,H,L,H,H 


L,L,H]. 




[c,L 


10 


x,x,x 


r X' 


-> 


H,H,L,H,H 


L,L,H] 




[C,H 


ENDIO 


x,x,x 


r X" 


-> 


H,H,L,H,H 


L,L,L], 




[c,L 


ENDIO 


x,x,x 


X. 


-> 


H,H,L,H,H 


L,L,L], 




[c,H 


FLOAT 


x,x,x 


r X 


-> 


H,H,H,H,H 


L,H,H] 




[c,L 


FLOAT 


x,x,x 


t X 


-> 


H,H,H,H,H 


L,H,H] 




[c,H 


FLOAT 


x,x,x 


X" 


-> 


H,H,H,H,H 


L,H,H] 




[c,L 


FLOAT 


x,x,x 


r X 


-> 


H,H,H,H,H 


L,H,H] 




[C,H 


FLOAT 


x,x,x 


f X 


-> 


H,H,H,H,H 


f L,H,H] 




[c,L 


FLOAT 


x,x,x 


f X 


-> 


H,H,H,H,H 


L,H,H] 




[c,H 


WAITING 


x,x,x 


r X 


-> 


H,H,H,H,H 


r H,H,H] 


• 


[c,L 


WAITING 


x,x,x 


, X 


-> 


H,H,H,H,H 


r H,H,H] 




[C,H 


WAITING 


x,x,x 


r X 


-> 


H,H,H,H,H 


H,H,H] 


"peripheral interrupt ack. 


[c,L 


SAMPLECS 


x,x,x 


f H 


-> 


H,H,H,H,H 


L,H,H] 




[c,H 


CMDDELAY 


x,x,x 


r X 


-> 


H,H,H,H,H 


f L,H,H] 




[c,L 


10 


L,L,L 


r X 


-> 


H,H,H,H,L 


L,L,H] 




[c,H 


10 


x,x,x 


r X 


-> 


H,H,H,H,L 


L,L,H] 




[c,L 


10 


x,x,x 


r X 


-> 


H,H,H,H,L 


L,L,H] 




[C,H 


10 


x,x,x 


t X' 


-> 


H,H,H,H,L 


L,L,H] 




[C,L 


10 , 


x,x,x 


x; 


-> 


H,H,H,H,L 


L,L,H], 




[c,H 


10 


x,x,x 


r x; 


-> 


H,H,H,H,L 


L,L,H] 




[C,L 


10 


x,x,x 


r x; 


-> 


H,H,H,H,L 


L,L,H] 




[c,H 


ENDIO 


x,x,x 


X" 


-> 


H,H,H,H,L 


L,L,L], 




[C,L 


ENDIO 


x,x,x 


X' 


-> 


H,H,H,H,L 


L,L,L] 




[c,H 


FLOAT 


x,x,x 


X' 


-> 


H,H,H,H,H 


L,H,H] 




[c,L 


FLOAT 


x,x,x 


X] 


-> 


H,H,H,H,H 


L,H,H], 




[C,H, 


FLOAT 


x,x,x 


x] 


-> 


H,H,H,H,H 


L,H,H] 




[c,L 


FLOAT 


x,x,x 


x; 


-> 


H,H,H,H,H 


L,H,H] 




[c,H 


FLOAT 


x,x,x 


x; 


-> 1 


H,H,H,H,H 


L,H,H] 




[c,L 


FLOAT 


x,x,x 


X' 


-> 


H,H,H,H,H 


L,H,H] 




[c,H 


WAITING 


x,x,x 


, X' 


-> 


H,H,H,H,H 


H,H,H] 


"lOOnS SRAM read 


tc,L 


SAMPLECS 


H,L,L 


r L' 


-> 


L,H,H,H,H 


L,H,H], 




{C,H 


NOTLOCAL 


x,x,x 


l: 


-> 


L,H,H,H,H 


L,L,L] 




[c,L 


NOTLOCAL 


x,x,x 


r X' 


-> 


L,H,H,H,H 


L,L,L] 




[c,H 


NOTLOCAL 


x,x,x 


X' 


-> 


H,H,H,H,H 


H,H,H] 


"peripheral write 


[C,L 


SAMPLECS 


x,x,x 


h: 


-> 


H,H,H,H,H 


L/H,H] 




[c,H 


CMDDELAY 


x,x,x 


r X" 


-> 


H,H,H,H,H 


L,H,H] 




[c,L 


, 10 


L,H,H 


f X' 


-> 


H,H,H,L,H 


L,L,H] 




[c,H 


10 


x,x,x 


r X' 


-> 


H,H,H,L,H 


L,L,H] 




[c,L 


, 10 


x,x,x 


, X 


-> 


H,H,H,L,H 


L,L,H] 




[c,H 


10 


x,x,x 


t X' 


-> 


H,H,H,L,H 


L,L,H] 




[c,L 


10 


x,x,x 


r X 


-> 


H,H,H,L,H 


L,L,H] 




[c,H 


10 


x,x,x 


r X 


-> 


H,H,H,L,H 


f L,L,H] 




[C,L 


, 10 


x,x,x 


t X 


-> 


H,H,H,L,H 


L,L,H] 




Cc,H 


10 


x,x,x 


r X" 


-> 


H,H,H,L,H 


L,L,H] 




[C,L 


10 


x,x,x 


r X 


-> ..'' 


H,H,H,L,H 


L,L,H] 




[C,H 


, ENDIO 


x,x,x 


t X' 


-> 


H,H,H,L,H 


L,L,L] 




[C,L 


, ENDIO 


x,x,x 


t x; 


-> 


H,H,H,H,H 


L,L,L] 




[c,H 


, FLOAT 


x,x,x 


r x; 


-> 


H,H,H,H,H 


L,H,H] 




[c,L 


, FLOAT 


x,x,x 


f X 


-> 


H,H,H,H,H 


L,H,H] 




end ] 


3us_Contro] 


L_386_P< 


M_: 


J; 









Figure A-2. PAL-2 State Listings (Cont'd.) 
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LOCAL BUS CONTROL PAL DESCRIPTIONS 



PAL16R8 


PAL DESIGN SPECIFICATIONS 


PART NUMBER: 80386 LOCAL BUS CONTROLLER - PAL 1 


80386 LOCAL BUS CONTROLLER : PAL 1 OF 2 


INTEL, SANTA CLARA, CALIFORNIA 


CLK2 CLK ADS READY WR CSOWS CSIWS CSIO RESET GND 


OE QO 


Ql LO LI L2 PIPE IDLE NA VCC 


/PIPE := 


RESET 




+ /CLK * /PIPE 




+ CLK * PIPE 




+ /PIPE * READY 




+ IDLE 




+ ADS * /PIPE 


/IDLE := 


/CLK * /IDLE * /RESET 




+ /IDLE * PIPE * /RESET 




+ /IDLE * READY * /RESET 




+ /ADS * CLK * /PIPE * /RESET 


/NA : = 


/LI 


+ 


L2 


+ 


/CLK * /NA 


+ 


CLK * LO * NA 


+ 


/LO * /NA * QO 


+ 


/LO * /NA * Ql 


/L2 : = 


/CLK * /LI * /L2 * /RESET 


+ 


/LO * /L2 * /NA * /RESET 


+ 


/LI * /L2 * READY * /RESET 


+ 


LO * LI * /L2 * QO * /RESET 


+ 


/LO * /LI * /RESET 


+ 


/CLK * CSOWS * CSIWS * CSIO * /IDLE * LO * LI * L2 * /RESET 


/LI : = 


RESET 


+ 


/CLK * LO * /LI 


+ 


LO * /LI * READY 


+ 


CSIWS * /LI * L2 


+ 


LO * /LI * L2 


+ 


LO * L2 * /QO * /Ql 


+ 


LO * /LI * /QO * /Ql 


+ 


/CLK * CSOWS * CSIWS * CSIO * /IDLE * LO * L2 


/LO : = 


/LO * /L2 * /RESET 


+ 


/LO * LI * QO * /RESET 


+ 


CSIWS * /CSIO * /LO * /LI * /RESET 


+ 


/ADS * CLK * CSIO * LO * /LI * L2 * /RESET 


+ 


/ADS * CLK * LO * /LI * L2 * /QO * /RESET 


+ 


CLK * CSIO * /IDLE * LO * /LI * L2 * /RESET 


+ 


CLK * /IDLE * LO * /LI * L2 * /QO * /RESET 


+ 


/ADS * CLK * /LI * /L2 * /QO * /Ql * /READY * /RESET 


/Ql : = 


RESET 


+ 


QO * /Ql 


+ 


CLK * QO 


+ 


LO * /Ql 


+ 


CSIWS * /LI * L2 * /Ql 


+ 


LI * /L2 * /Ql 


/QO : = 


RESET 


+ 


/CLK * /QO * Ql 


+ 


CLK * QO * /Ql 


+ 


/LO * LI * L2 * /QO * /Ql 


+ 


LO * /LI * /QO * /Ql 


+ 


CSIWS * /LI * L2 * /QO * /Ql 


+ 


/LI * /L2 * /QO * /Ql * WR 


+ 


/LO * LI * /NA * /QO * /Ql 


DESCRIPTION 


This 


PAL is the first of two PALs that implement a 386 bus controller 



Figure A-3. PAL-1 Equations 
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LOCAL BUS CONTROL PAL DESCRIPTIONS 



PAL16R8 PAL DESIGN SPECIFICATIONS 

PART NUMBER: 80386 LOCAL BUS CONTROLLER - PAL 2 

80385 LOCAL BUS CONTROLLER : PAL 2 OF 2 

INTEL, SANTA CLARA, CALIFORNIA 

CLK2 CLK MIO DC WR LO LI L2 CSOWS GND 

OE RDY DEN ALE INTA lOWC lORC MWTC MRDC VCC 



/MRDC := /LO * LI * /MRDC 

+ LI * /L2 * /MRDC 

+ /CLK * LO * /L2 * /MRDC 

+ LO * /L2 * /MRDC * RDY 

+ /CSOWS * /LO * /LI * L2 * MIO * /WR 

+ DEN * /LO * LI * MIO * /WR 

+ DEN * LI * /L2 * MIO * /WR 

/MWTC := LO * LI * /L2 * /MWTC 
+ /LO * LI * /MWTC * RDY 
+ LO * /L2 * /MWTC * RDY 
+ /CSOWS * DC * /LO * /LI * L2 * MIO * WR 
+ DC * DEN * /LO * LI * MIO * WR 
+ DC * DEN * LI * /L2 * MIO * WR 

/lORC := /lORC * /LO * LI 
+ /lORC * LI * /L2 
+ /CLK * /lORC * LO * /L2 
+ /lORC * LO * /L2 * RDY 

+ /CSOWS * DC * /LO * /LI * L2 * /MIO * /WR 
+ DC * DEN * /LO * LI * /MIO * /WR 
+ DC * DEN * LI * /L2 * /MIO * /WR 

/lOWC := /lOWC * LO * LI * /L2 
+ /lOWC * /LO * LI * RDY 
+ /lOWC * LO * /L2 * RDY 
+ /CSOWS * DC * /LO * /LI * L2 * /MIO * WR 
+ DC * DEN * /LO * LI * /MIO * WR 
+ DC * DEN * LI * /L2 * /MIO * WR 

/INTA := /INTA * /LO * LI 
+ /INTA * LI * /L2 
+ /CLK * /INTA * LO * /L2 
+ /INTA * LO * /L2 * RDY 

+ /CSOWS * /DC * /LO * /LI * L2 * /MIO * /WR 
+ /DC * DEN * /LO * LI * /MIO * /WR 
+ /DC * DEN * LI * /L2 * /MIO * /WR 

/ALE := /ALE * /CLK * /CSOWS * /L2 
+ /ALE * /CLK * /DEN * /L2 
+ /ALE * /CSOWS * /L2 * RDY 
+ /LO 
+ LI 
+ /ALE * /DEN * /L2 * RDY 

/DEN := /LO * LI 
+ LI * /L2 
+ /lOWC * LI 
+ LI * /MWTC 

+ /CLK * /DEN * LO * /L2 
+ /DEN * LO * /L2 * RDY 
+ /ALE * /CLK * /CSOWS * LO * /L2 
+ /ALE * /CSOWS * LO * /L2 * RDY 



/RDY := /LO * 


LI * 


L2 








+ /CLK 


* LO * 


/L2 ' 


' /RDY 






+ CLK * 


/DEN 


* LO ■* 


' LI * 


/L2 * 


^DY 


+ CLK * 


/INTA 


* LO 


* /LI 


* /L2 


* RDY 


+ CLK * 


/lORC 


* LO 


*/Ll 


* /L2 


* RDY 


+ CLK * 


LO * 


/LI * 


/L2 * 


/MRDC 


* RDY 


+ CLK * 


/DEN 


* /lOWC * LC 


) * /L2 


* RDY 


+ CLK * 


/DEN 


* LO ■* 


c /L2 ^ 


' /MWTC 


* RDY 


DESCRIPTION 













This PAL is the second of two PALs that implement a 386 bus controller 



Figure A-4. PAL-2 Equations 
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Description 



APPENDIX B 
80387 EMULATOR PAL DESCRIPTION 



This section describes the PAL equations for the Math Control PAL in the 80386 emulator 
circuit. These equations are listed in Figure B- 1 . 

The primary function of the PAL is to decode the 80386 outputs and generate 80287 inputs. 
The CLK16D#, DVALID#, and AVALID# signals provide for the correct timing of the 
outputs. The TP2 input provides the ability to force the PAL outputs to the high impedance 
state. For normal operation, TP2 is pulled high. 



PAL16L8B PAL DESIGN SPECIFICATION 

386/100 27 February 1986 ED JACKS 

PAL: MATH CYCle MATHCYC 

INTeL Corporation 

/RDY A31 LRESET /ADS MIO /RD /AVALID /DVALID /CLK16 GND 

TP2 /CLK16D /READYO /DVALIDD /AVALIDD NC /lORDD /IDWCD /READYOD VCC 

IF (TP2) AVALIDD - ADS » RDY » /LRESET * CLK16 • /AVALID 
+ /RDY ♦ A31 * /MID * /LRESET * AVALID 
+ A31 • /MID • /LRESET • AVALID * DVALID 
+ ADS * /LRESET * CLK16 ♦ /AVALID * DVALID 

♦ /LRESET * /CLK16 * AVALID 

IF (TP2) DVALIDD - /LRESET * CLK16 • AVALID • DVALID 
+ /RDY » /LRESET ♦ DVALID 

♦ ADS * /LRESET • CLK16 * /DVALID 
+ /LRESET * /CLK16 • DVALID 

IF (TP2) lORDD - /RDY • A31 * /MIO * /RD * AVALID * DVALID 
+ A31 * /MIO • /CLK16 • RD • AVALID * DVALID 

IF (TP2) lOWCD - /RDY • A31 * /MIO • RD • AVALID * DVALID 
+ A3 1 * /MIO • /CLK16 • /RD » AVALID » DVALID 

IF (TP2) READYOD - A31 * /MIO * /CLK16 • READYO * AVALID • DVALID 
+ /RDY • A31 • /MIO * CLK16 • AVALID * DVALID 

CLK16D - /LRESET • /CLK16 



Figure B-1. 80387 Emulator PAL Equations 
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APPENDIX C 
DRAM PAL DESCRIPTIONS 



This section describes the inputs, outputs, and functions of each of the PALs in the DRAM 
design described in Chapter 6. The terms Start-Of-Phase and Middle-Of-Phase used to 
describe PAL input sampling times refer to the 80386 internal CLK phase and are defined 
in Figure C-1. 

The setup, hold, and propagation delay times for each PAL input and output can be deter- 
mined from the PAL data sheets. In a few cases, the setup and hold times during certain 
events must be violated; in these cases, the PAL equations mask these inputs so they are not 
sampled. Because the states are fully registered and because inputs are masked when their 
setup or hold times cannot be guaranteed, no hazards exist. 



DRAM STATE PAL 

The DRAM State PAL determines when to run a new DRAM cycle and tracks the state of 
the DRAM through the cycle. The inputs sample DRAM requests from the processor (or 
any other bus master) as well as requests for refresh. The outputs store state information 
and generate the two RAS signals and two multiplexer control signals. Table C-1 contains 
a description of the outputs and inputs. 

The equations for the 3-CLK DRAM State PAL are shown in Figure C-2; those for the 
2-CLK DRAM State PAL are shown in Figure C-3. The DRAM State PAL is implemented 
in a 16R8 PAL if the RAS signals are registered internally, or in a 16R6 PAL if external 
registers are used. For a 16-MHz system, B-series PAL speeds are required. 



START-O 
CLK2 \ / 


FPHASE 


MIDDLEO 


FPHASE 


START-0 

/ 


F-PHASE 


MIDDLEO 


F-PHASE 


\ 


\ 


\ 

^ 


CLK 


\ 


/ 




r' 


G30107 











Figure C-1. PAL Sampling Edges 
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DRAM PAL DESCRIPTIONS 



Table C-1. DRAM State PAL Pin Description 



PAL CONTROLS 




Name 


Connects From 


PAL Usage 




CLK2 


Systems CLK2 


PAL register clock 




OE 


Tied low 


Outputs always enabled 




PAL INPUTS 


Name 


Connects From 


PAL Usage 


Sampled 


CLK 


System CLK 


Indicates clock phase 


Every CLK2 


CSO# 
CS1# 
CS2# 
CS3# 
CS4# 


Chip-Select Logic 
(uses Address, 
M/IO, W/R, D/C) 


DRAM access is begun (or 
queued if another cycle is in 
progress) when all selects 
are sampled active 


Start-Of-Phase 
(Queue cleared 
after first cycle of 
access) 


DT/R# 


DRAM CONTROL 
PAL DT/R# out 


Indicates write/read 
Used only in 2-CLK 


Start-Of-Phase on 
2nd CLK of access 


A2 


System Address 
bit 2 


Selects one of the two DRAM 
banks 


Start-Of-Phase in 
which DRAM 
access starts 


RFRQ 


Refresh Interval 
Count 


Starts refresh cycle as soon 
as possible 


Middle-Of-Phase 


PAL OUTPUTS 


Name 


Connects To 


PAL Usage 


Changes State 


RASO# 


DRAM Bank 


Controls DRAM RAS signals 


Start-Of-Phase 


RAS1# 


DRAM Bank 1 


ROWSEL 


Addr MUX select 


Select DRAM row/column 


MIddle-Of-Phase 


MUXOE# 


Addr MUX enable 


Disable MUX on refresh 


Middle-Of-Phase 


A2REG 


Not connected 


Store active DRAM bank 




DRAMSELECT 


Not connected 


Queue DRAM requests 




QO 


For NA in 2-CLK 


Stores PAL State 




01 


Not connected 
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DRAM PAL DESCRIPTIONS 



PAL16R8 PAL DESIGN SPECIFICATIONS 

PART NUMBER: 3-CLK DRAM STATE PAL 

DRAM STATE PAL OF INTERLEAVED DRAM CONTROLLER FOR 80386 SYSTEMS 

INTEL, SANTA CLARA, CALIFORNIA 

CLK2 CLK A2 CSO CSl CS2 CSS CS4 RFRQ GND 

OE RASO ROWSEL MUXOE QO Ql A2REG DRAMSELECT RASl VCC 

/DRAMSELECT := CSO * /DRAMSELECT 
+ CSl * /DRAMSELECT 
+ CS2 * /DRAMSELECT 
+ /CS3 * /DRAMSELECT 
+ /CS4 * /DRAMSELECT 
+ /CLK * /DRAMSELECT 
+ /MUXOE * ROWSEL * /Ql * /QO * /CLK 

/ROWSEL := /ROWSEL * QO * CLK 
+ /ROWSEL * /Ql 

+ ROWSEL * /Ql * /QO * /CLK 

+ ROWSEL * /Ql * QO * /CLK * MUXOE * RFRQ 

/Ql:= ROWSEL * /Ql * /QO * /CLK 
+ ROWSEL * QO * CLK 
+ /ROWSEL * /QO * CLK 
+ ROWSEL * Ql * /QO * CLK * /CSO * /CSl * /CS2 * CSS * CS4 

* /MUXOE * A2 * A2REG 

+ ROWSEL * Ql * /QO * CLK * /CSO * /CSl * /CS2 * CSS * CS4 

* /MUXOE * /A2 * /A2REG 

4- ROWSEL * /Ql * QO * /CLK * /MUXOE 
+ ROWSEL * /Ql * QO * /CLK * /RFRQ 

/QO := /ROWSEL * Ql * QO * /CLK 
+ /ROWSEL * /QO * Ql * CLK 
+ ROWSEL * /Ql * /QO * /CLK 
+ ROWSEL * Ql * CLK * /CSO * /CSl * /CS2 * CSS * CS4 

* /MUXOE * A2 * A2REG 

+ ROWSEL * Ql * CLK * /CSO * /CSl * /CS2 * CSS * CS4 

* /MUXOE * /A2 * /A2REG 

+ ROWSEL * /Ql * QO * CLK * /CSO * /CSl * /CS2 * CSS * CS4 * /MUXOE 
+ ROWSEL * /Ql * QO * CLK * DRAMSELECT * /MUXOE 
+ ROWSEL * /Ql * QO * /CLK * MUXOE * RFRQ 

/RASO := ROWSEL * /Ql * /QO * /CLK * /A2REG 
+ ROWSEL * /Ql * /QO * /CLK * MUXOE 
+ /ROWSEL * /A2REG 
+ /ROWSEL * MUXOE 
+ ROWSEL * Ql * CLK * /A2 * /A2REG * /CSO * /CSl * /CS2 * CSS * CS4 

* /MUXOE 

+ ROWSEL * /Ql * QO * CLK * /A2 * /CSO * /CSl * /CS2 * CSS * CS4 

* /MUXOE 

+ ROWSEL * /Ql * QO * CLK * /A2 * DRAMSELECT * /MUXOE 

/RASl := ROWSEL * /Ql * /QO * /CLK * A2REG 
+ ROWSEL * /Ql * /QO * /CLK * MUXOE 
+ /ROWSEL * A2REG 
+ /ROWSEL * MUXOE 
+ ROWSEL * Ql * CLK * A2 * A2REG * /CSO * /CSl * /CS2 * CSS * CS4 

* /MUXOE 

+ ROWSEL * /Ql * QO * CLK * A2 * /CSO * /CSl * /CS2 * CSS * CS4 

* /MUXOE 

+ ROWSEL * /Ql * QO * CLK * A2 * DRAMSELECT * /MUXOE 

/MUXOE := /MUXOE * /QO 
+ /MUXOE * CLK 
+ /MUXOE * /ROWSEL * /Ql 
+ /RFRQ * ROWSEL * /Ql * QO * /CLK 
+ /MUXOE * /RFRQ * Ql * QO * /CLK 

/A2REG := /A2REG * /QO 

+ /A2REG * Ql * CLK 

+ /A2REG * ROWSEL * Ql 

+ /A2REG * /ROWSEL * /Ql 

+ A2REG * /ROWSEL * Ql * QO * /CLK 

+ /A2 * ROWSEL * /Ql * QO 



Figure C-2. 3-CLK DRAM State PAL Equations 
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DRAM PAL DESCRrPTIONS 



FUNCTION TABLE 
















OE CLK2 CLK 


CSO CSI 


CSS 


CS3 


CS4 


A2 RFRQ 


;inputs 


ROWSEL Ql QO 

. AC 


RASO RASl 


MUXOE 


DRAMSELECT A2REG ; outputs 1 




CLK2 


















1 CLK 






ROWSEL 










1 1 /cso 






Q] 












1 1 1 /csi 






QO 










MM /CS2 








1 /RASO 








MM CSS 






1 1 /RASl 










CS4 




1 1 1 /MUXOE 










A2 




1 1 1 


1 DRAMSELECT 










1 RFRq 




1 1 1 


1 1 A2REG 






M M 1 




1 1 




1 1 1 


1 1 1 


STATE 


COMMENTS 




L C H H X X X 


X 


X L 


XXXXXXXX 


X 


initialize to IDLE 


L C L H X X X 


X 


X L 


X X 


XXX 


XXX 


X 


initialize to IDLE 


L C H H X X X 


X 


X L 


X X X X X 


XXX 


X 


initialize to IDLE 


L C L H X X X 


X 


X L 


XXXXXXXX 


X 


initialize to IDLE 


L C H H X X X 


X 


X L 


X X 


XXX 


XXX 


X 


initialize to IDLE 


L C L H X X X X 


X L 


XXXXXXXX 


X 


initialize to IDLE 


L C H H X X X 


X 


X L 


X X 


XXX 


XXX 


X 


initialize to IDLE 


L C H H X X X 


X 


X L 


L L 


H L H 


L L L; 


ACCESS3 


continue DRAM cycle 


L C L X X X X 


X 


X L 


L H H L H 


L L L; 


ACCESS4 


continue DRAM cycle 


L C H H X X X 


X 


X L 


L H 


H L H 


L L L; 


ACCESS5 


continue DRAM cycle 


L C L X X X X 


X 


X L 


H H 


L L H 


L L H; 


ACCESS6 


continue DRAM cycle 


L C H H X X X 


X 


X L 


H H 


H H H 


L L H; 


PRECHAR6E1 


no dram request pending 


L C L X X X X 


X 


X L 


H H 


H H H 


L L H; 


PRECHARGE2 


wait for precharge 


L C H L L L H 


H 


H L 


H L 


L H L 


L H H; 


ACCESSl 


start DRAM cycle to other bank 


L C L X X X X 


X 


X L 


L L 


L H L 


L L H; 


ACCESS2 


continue DRAM cycle 


L C H H X X X 


X 


X L 


L L 


H H L 


L L H; 


ACCESS3 


continue DRAM cycle 


L C L X X X X 


X 


X L 


L H 


H H L 


L L H; 


ACCESS4 


continue DRAM cycle 


L C H H X X X 


X 


X L 


L H 


H H L 


L L H; 


ACCESS5 


continue DRAM cycle 


L C L X X X X 


X 


X L 


H H 


L H L 


L L L 


ACCESS6 


continue DRAM cycle 


L C H H X X X 


X 


X L 


H H 


H H H 


L L L 


PRECHARGEl 


no dram request pending 


L C L X X X X 


X 


X L 


H H 


H H H 


L L L 


PRECHARGE2 


wait for precharge 


L C H H X X X 


X 


X L 


H L 


H H H 


L L X 


IDLEl 


no dram request pending 


L C L X X X X 


X 


X L 


H L 


H H H 


L L X 


IDLE2 


wait for precharge 


L C H H X X X 


X 


X H 


H L 


H H H 


L L X 


IDLEl 


no dram request pending 


L C L X X X X 


X 


X H 


H L 


H H H 


H L X 


IDLE2 


refresh request sampled 


L C H L L L H 


H 


H H 


H L 


H H H 


H H H 


IDLEl 


can't start: refresh pending 


L C L X X X X 


X 


X H 


L H 


L H H 


H H X 


REFSTART2 


refresh address set-up 




L C H H X X X 


X 


X H 


H L 


L L L 


H H X 


ACCESSl 


start refresh cycle 




L C L H X X X 


X 


X L 


X X 


X X X X X X 


X 


initialize to IDLE 


L C H H X X X 


X 


X L 


XXXXXXXX 


X 


initialize to IDLE 


L C L H X X X 


X 


X L 


X X X X X 


XXX 


X 


initialize to IDLE 


L C H H X X X 


X 


X L 


X X 


XXX 


XXX 


X 


initialize to IDLE 


L C L H X X X 


X 


X L 


X X 


XXX 


XXX 


X 


initialize to IDLE 


L C H H X X X 


X 


X L 


H L 


H H H 


L L X 


, IDLEl 


remain in IDLE 


L C L X X X X 


X 


X L 


H L 


H H H 


L L X 


. IDLE2 


remain in IDLE 


L C H X H X X 


X 


X L 


H L 


H H H 




; IDLEl 


remain in IDLE 


L C L X X X X X 


X L 


H L 


H H H 




; IDLE2 


remain in IDLE 


L C H X X H X 


X 


X L 


H L 


H H H 




; IDLEl 


remain in IDLE 


L C L X X X X 


X 


X L 


H L 


H H H 




; IDLE2 


remain in IDLE 


L C H L L L H 


H 


L L 


H L 


L L H 




; ACCESSl 


start DRAM cycle 


L C L X X X X 


X 


X L 


L L 


L L H 




; ACCESS2 


continue DRAM cycle 


L C H X X X L 


X 


X L 


L L 


H L H 




; ACCESS3 


continue DRAM cycle 


L C L X X X X 


X 


X L 


L H 


H L H 




; ACCESS4 


continue DRAM cycle 


L C H L L L H 


H X L 


L H 


H L H 


L H L 


; ACCESS5 


continue DRAM cycle new request 


L C L X X X X X 


X L 


H H 


L L H 


L H H 


; ACCESS6 


continue DRAM cycle 


L C H L L L H 


H 


H L 


H L 


L H L 


L H H 


; ACCESSl 


start DRAM cycle to other bank 


L C L X X X X 


X 


X L 


L L 


L H L 


L L H 


; ACCESS2 


continue DRAM cycle 


L C H X X X L 


X 


X L 


L L 


H H L 


L L H 


; ACCESS3 


continue DRAM cycle 


L C L X X X X 


X 


X L 


L H 


H H L 


L L H 


; ACCESS4 


continue DRAM cycle 


L C H X X X X 


L 


X L 


L H 


H H L 


L L H 


; ACCESS5 


continue DRAM cycle 


L C L X X X X 


X 


X L 


H H 


L H L 


L L L 


; ACCESS6 


continue DRAM cycle 


L C H L L L H 


H 


H L 


H H 


H H H 


L H L 


; PRECHARGEl 


can't start same bank cycle 



Figure C-2. 3-CLK DRAM State PAL Equations (Cont'd.) 
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DRAM PAL DESCRIPTIONS 



X L 
H L 
X L 
H H 
X H 



H H H H 



H H 
X X 



H H H H 
X X X H 
H H H 
XXX 



L H H 

L H H 

L L H 

L L H 

L H H 

H H H 

H H H 

H H L H 

H H H H 

H H H H 

H L H H 

L H L H 



L 

L 

L 

L 

L 

L 

L 

L 

H H 
H H H 
H H H 
H H H 
H H H 



L 
L 
L 

H H 

H H 

H H L 

H H H 

H H H 

L H H 

L H H 

L L L 

L L L 



H H 

H H 

H H 

H H 

H H 

H H 

H H H 

H H H 

H H H 

H L H 

H L H 

H L L 



PRECHARGE2 wait for precharge 

IDLEl can*t start same bank cycle 
IDLE2 wait for precharge 
ACCESSl start DRAM cycle to same bank 
ACCESS2 continue DRAM cycle 
ACCESS3 continue DRAM cycle 
ACCESS4 continue DRAM cycle 
ACCESS5 continue DRAM cycle new request 
ACCESS6 continue DRAM cycle refresh req 
PRECHARGEl can't start: refresh pending 
PRECHARGE2 wait for precharge 

IDLEl can't start: refresh pending 
REFSTART2 wait for precharge 
ACCESSl start refresh cycle 
ACCESS2 continue refresh cycle 
ACCESS3 continue refresh cycle 
ACCESS4 continue refresh cycle 
ACCESS5 continue refresh cycle 
ACCESS6 continue refresh cycle 
PRECHARGEl can't start: refresh precharge 
PRECHARGE2 wait for precharge 

IDLEl can't start: refresh precharge 
IDLE2 wait for precharge 
ACCESSl start DRAM cycle 
ACCESS2 continue DRAM cycle 



DESCRIPTION 

*** NOTE - SOME VERSIONS OF PALASM WILL CRASH IF THE FILE IS TOO LONG *** 

*** IF YOURS DOES, DELETE THIS DESCRIPTION (FROM HERE TO END-OF-FILE) *** 

This PAL implements the main state machine of the DRAM controller. 
The state machine is described below. 

For brevity, the following keywords are used 

SELECT = (/CSC * /CSl * /CS2 * CS3 * CS4 * CLK) 

;chip selects and clock must be active to select 

SELECTED « (SELECT + DRAMSELECT) ;true if DRAM is now or has been selected 

STARTACCESS = (SELECTED * /MUXOE); start dram access cycle from idle 

The states are defined below and indicated by [ROWSEL:Q1:QO:CLK]. 

The 4-bit binary number following the state name represents these four signals. 



I state REFSTART2 



/RASO 
I /RASl 
I MUXOE 



ON 
ON 
MUXOE 



0101 ;cycle preceding refresh | 
;next cycle is first RAS for refresh] 

I- 
;maintain MUXOE state | 
==================== _„___„/ 

I MUXOE * RFRQ 



h 



state IDLEl = 1010 
I /RASO := OFF 
I /RASl := OFF 
I MUXOE := RFRQ 

v========================== 

I 

|/(MUXOE * RFRQ) 

V 



=\ 
I 

l<- 
I 

; sample refresh request | 
===========================/ 



;waiting for access or refresh 
;both RAS's idle 



I /STARTACCESS 



always 



Figure C-2. 3-CLK DRAM State PAL Equations (Cont'd.) 



C-5 



iny 



DRAM PAL DESCRIPTIONS 



state IDLE2 



/RASO 
/RASl 
A2REG 
MUXOE 



1011 ;waiting for access or refresh 






= {/A2 
= { A2 
= A2 
= MUXOE 



STARTACCESS) 
STARTACCESS) 



; start access 

; sample A2 state 
;maintain MUXOE state 



I state ACCESSl 



1000 



/RASO 
/RASl 
A2REG 
MUXOE 



I STARTACCESS 

V 

;first cycle of access or refresh|<--+ 



= /A2REG + MUXOE ;RAS corresponding to A2 
= A2REG + MUXOE ;or refresh |<- 

= A2REG ;maintain state of sampled A2| 
= MUXOE ;inaintain MUXOE state |<- 

———:: = =: s:=s:s:ss:s=ss's:r:sssssssss==:=:==s===:sss=ss:sssr=:=3r/ 



i always 

V 

______ „_= „ \ 

state ACCESS2 = 0001; second cycle of access or refresh | 



/RASO 
/RASl 
A2REG 
MUXOE 



/A2REG 
= A2REG 
= A2REG 
= MUXOE 



MUXOE ;RAS corresponding to A2 | 
MUXOE ;or refresh | 

;niaintain state of sampled A2| 
;maintain MUXOE state | 



state ACCESS3 



\- 



/RASO 
/RASl 
A2RE6 
MUXOE 



I 

I always 

V 

0010 ;third cycle of access or refresh | 



- /A2REG + MUXOE ;RAS corresponding to A2 
= A2REG + MUXOE ;or refresh 

= A2REG ;maintain state of sampled A2 
= MUXOE ;maintain MUXOE state 



I always 

V 

state ACCESS4 = 0111;fourth cycle of access or refresh! 



I I 
I I I 



/RASO 
/RASl 
A2REG 
MUXOE 



/A2REG 
A2REG 
A2REG 
MUXOE 



MUXOE ;RAS corresponding to A2 | 

MUXOE ;or refresh | 

;maintain state of sampled A2| 

;maintain MUXOE state | 



i always 




state ACCESS5 =1110 ;fifth cycle of access or refresh 
= /A2REG + MUXOE ;RAS corresponding to A2 
= A2REG + MUXOE ;or refresh 

= /A2REG ; invert state of sampled A2 
= MUXOE + RFRQ ; sample refresh request 



=\ 



=/ 



state ACCESS6 



always! 

V 



(STARTACCESS 



(( A2 
+(/A2 



/RASO 
/RASl 
A2REG 
MUXOE 



1101 ;sixth cycle of access or refresh! 



A2REG) 
/A2REG))) 



= /A2 * /A2REG * STARTACCESS; start next... j 
= A2 * A2REG * STARTACCESS; interleave acces!- 
= A2REG ;maintain state of interleave A2| 
= MUXOE ;maintain MUXOE state | 
==================/ 



! 
!/(STARTACCESS 

V 



(( A2 
+ (/A2 



A2REG) 
/A2REG))) 



Figure C-2. 3-CLK DRAM State PAL Equations (Cont'd.) 



C-6 



Intel 
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state PRECHARGEl = 1110 ; first precharge after access 
= OFF ;both RAS's idle 

= OFF 

= A2REG ;maintain state of interleave A2 
= MUXOE + RFRQ ; sample refresh request 




I 
always! 



=/ 



state PRECHARGE2 



/RASO 
/RASl 
A2REG 
MUXOE 



(STARTACCESS * (( A2 * A2REG) 
V +(/A2 * /A2REG))] 

============ ____„____=\ 

1111 ;second precharge after access | 



= /A2 * /A2REG * STARTACCESS; start next... | 
= A2 * A2REG * STARTACCESS interleave acces|- 
= A2REG ;maintain state of interleave A2| 
= MUXOE ;maintain MUXOE state | 



/(STARTACCESS * (( A2 * A2REG) | 
+(/A2 * /A2REG)))+- 



Finally, the Karnaugh maps for the following signals are: 



Q1\CLK 


00 


01 


11 


10 






V_ 












MUXOE 


00 1 




MUX 




MUX 


key: 




01 1 




MUX 


MUX 


M+R 


MUX 


= MUXOE 


11 1 




MUX 


MUX 


M+R 


M+R 


= MUXOE + RFRQ 


10 1 


MUX 




MUX 


RFR 


RFR 


= RFRQ 


ROWSEL\QO 














Q1\CLK 


00 


01 


11 


10 






\ 












A2REG 


00 




A2R 




A2R 


key: 




01 




A2R 


A2R 


/A2R 


A2; 


= A2 


11 




A2R 


A2R 


A2R 


A2R 


= A2REG 


10 


A2R 




A2; 


A2; 






ROWSEL\QO 














Q1\CLK 


00 


01 


11 


10 






\ 












RAS signals 


00 




/AM AM 




/AM AM 


key: 


[RAS0:RAS1] 


01 




ON ON /AM AM 


/AM AM 


AM = 


A2REG + MUXOE 


11 




/AI AI 


/AI AI 


OFFOFF 


AS = 


A2 * STARTACCESS 


10 1 /AM AM 




/AS AS 


OFFOFF 


AI = 


A2 * STARTACCESS 


ROWSEL\QO 














Q1\CLK 


00 


01 


11 


10 






\ 












ROWSEL state 



* interleave 



00 1 0010 0111 

01 I 1000 0110 1101 
11 I liiO lOiO 1111 
10 I 0001 lOsO mMml 



key: [ROWSEL: Q1:Q0:CLK] 
M = MUXOE * RFRQ 
S = STARTACCESS 
I = STARTACCESS * interleave 



ROWSEL\QO 










Q1\CLK 00 


01 


11 


10 




\ 








Ql state circled 


00 1 


0010 




0111 




01 


1000 


0110 


1101 




11 


liiO 


lOiO 


1111 




10 1 0001 




lOsO 


mMml 




ROWSEL\QO 










Q1\CLK 00 


01 


11 


10 




\ 








QO state circled 


00 


0010 




0111 




01 


1000 


0110 


1101 




11 


liiO 


lOiO 


nil 




10 1 0001 




lOsO 


mMml 





Figure C-2. 3-CLK DRAM State PAL Equations (Cont'd.) 
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DRAM PAL DESCRIPTIONS 



PAL DESIGN SPECIFICATIONS 



PAL15R6 

PART NUMBER: 2-CLK DRAM STATE PAL 

DRAM STATE PAL OF INTERLEAVED DRAM CONTROLLER FOR 80386 SYSTEMS 

INTEL, SANTA CLARA, CALIFORNIA 

CLK2 CLK A2 CSO CSl CS2 CS3 DT%R RFRQ GND 

OE RASO ROWSEL MUXOE QO Ql A2REG DRAMSELECT RASl VCC 



/DRAMSELECT 



= CSO * /DRAMSELECT 
+ CSl * /DRAMSELECT 
+ CS2 * /DRAMSELECT 
+ /CS3 * /DRAMSELECT 
+ /CLK * /DRAMSELECT 
+ /MUXOE * ROWSEL * /Ql 



/QO * /CLK 



:= /ROWSEL 


* QO * 


CLK 




+ /ROWSEL 


* /Ql 






+ ROWSEL * 


/Ql * 


/QO 


* /CLK 


+ ROWSEL * 


/Ql * 


QO * 


/CLK 



MUXOE * RFRQ 



/Ql:= ROWSEL * /Ql * /QO ' 
+ ROWSEL * QO * CLK 
+ Ql * /QO * CLK 
+ /ROWSEL * /Ql * /QO 
+ ROWSEL * /Ql * QO * 
+ ROWSEL * /Ql * QO * 

/QO := /ROWSEL * Ql * QO * 
+ /ROWSEL * /QO * Ql 
+ ROWSEL * /Ql * /QO 
+ ROWSEL * Ql * CLK * 

* /MUXOE * A2 
+ ROWSEL * Ql * CLK * 

* /MUXOE * /A2 
+ ROWSEL * /Ql * QO * 
+ ROWSEL * /Ql * QO * 
+ ROWSEL * /Ql * QO * 



/CLK 



* CLK 
/CLK * 
/CLK * 



' DT%R * 

/MUXOE 

/RFRQ 



/MUXOE 



/CLK 
"^ CLK 
" /CLK 

/CSO * /CSl * /CS2 * CS3 
" A2REG 

/CSO * /CSl * /CS2 * CS3 
" /A2REG 

CLK * /CSO * /CSl * /CS2 * 
CLK * DRAMSELECT * /MUXOE 
/CLK * MUXOE * RFRQ 



CS3 * /MUXOE 



/RASO 



/RASl 



ROWSEL * 
ROWSEL * 
/ROWSEL 
/ROWSEL 
ROWSEL * 
ROWSEL * 
ROWSEL * 



/Ql * /QO 
/Ql * /QO 
' /A2REG 
' MUXOE 
Ql * CLK * 
/Ql * QO * 
/Ql * QO * 



/CLK * /A2REG 
/CLK * MUXOE 



/A2 * /A2REG * /CSO * /CSl * /CS2 * CS3 * /MUXOE 
CLK * /A2 * /CSO * /CSl * /CS2 * CS3 * /MUXOE 
CLK * /A2 * DRAMSELECT * /MUXOE 



ROWSEL * /Ql * /QO * /CLK * A2REG 



+ ROWSEL * /Ql * /QO 
+ /ROWSEL * A2REG 
+ /ROWSEL * MUXOE 
+ ROWSEL * Ql * CLK * 
+ ROWSEL * /Ql * QO * 
+ ROWSEL * /Ql * QO * 



A2 * A2REG * /CSO * /CSl * /CS2 * CSS * /MUXOE 
CLK * A2 * /CSO * /CSl * /CS2 * CS3 * /MUXOE 
CLK * A2 * DRAMSELECT * /MUXOE 



/MUXOE 



/A2REG 



= /MUXOE 

+ /MUXOE 

-f /MUXOE 

+ /RFRQ * 

+ /MUXOE 

= /A2REG 
+ /A2REG 
+ /A2REG 
+ /A2REG 
+ A2REG 



'/QO 

' /ROWSEL * /Ql 
ROWSEL * /Ql * QO * /CLK 
' /RFRQ * Ql * QO * /CLK 



/QO 

Ql * CLK 
ROWSEL * Ql 
/ROWSEL * /Ql 
/ROWSEL * Ql 



+ /A2 * ROWSEL * /Ql * QO 



QO * /CLK 



Figure C-3. 2-CLK DRAM State PAL Equations 
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DRAM PAL DESCRIPTrONS 



FUNCTION TABLE 










OE CLK2 CLK CSO CSl 


CS2 CSS 


CS4 


A2 RFRQ 


; inputs 


ROWSEL Ql QO RASO RASl MUXOE 


DRAMSELECT A2REG ; outputs 1 




1 CLK2 












1 1 CLK 


ROWSEL 










1 /CSO 


1 Ql 










1 /CSl 


1 QO 










1 /CS2 


1 /RASO 








1 CSS 


1 1 /RASl 








1 1 DT%R 


1 1 /MUXOE 








1 1 1 A2 


1 1 


1 DRAMSELECT 






1 III RFRQ 


1 i 


1 A2REG 






1 1 1 1 1 


1 1 - 


1 1 


STATE 


COMMENTS 




L C L H X X X X X l" 


X X X X X 


XXX; 


X 


initialize to IDLE 


LCHHXXXXXL 


XXXXXXXX; 


X 


initialize to IDLE 


LCLHXXXXXL 


X X X X X 


XXX; 


X 


initialize to IDLE 


LCHHXXXXXL 


X X X X X 


XXX; 


X 


initialize to IDLE 


LCLHXXXXXL 


XXXXXXXX; 


X 


initialize to IDLE 


LCHHXXXXXL 


X X X X X 


XXX; 


X 


initialize to IDLE 


LCLHXXXXXL 


X X X X X 


XXX; 


X 


initialize to IDLE 


LCHHXXXXXL 


XXXXXXXX; 


X 


initialize to IDLE 


LCLHXXXXXL 


XXXXXXXX 


X 


initialize to IDLE 


LCHHXXXXXL 


XXXXXXXX- 


X 


initialize to IDLE 


LCLHXXXXXL 


XXXXXXXX 


X 


initialize to IDLE 


LCHHXXXXXL 


H L H H H 


L L X 


IDLEl 


remain in IDLE 


L C L X X X X X X L 


H L H H H 


L L X 


IDLE2 


remain in IDLE 


L C H X H X X X X L 


H L H H H 


L L X 


IDLEl 


remain in IDLE 


LCLXXXXXXL 


HLHHHLLX 


IDLE2 


remain in IDLE 


LCHXXHXXXL 


H L H H H 


L L X 


IDLEl 


remain in IDLE 


LCLXXXXXXL 


H L H H H 


L L X 


IDLE2 


remain in IDLE 


LCHLLLHXLL 


H L L L H 


L H L 


ACCESSl 


start DRAM cycle 


LCLXXXXXXL 


L L L L H 


L L L 


ACCESS2 


continue DRAM cycle 


LCHXXXLHXL 


L L H L H 


L L L 


ACCESS3 


continue DRAM cycle: it's write 


LCLXXXXXXL 


L H H L H 


L L L 


ACCESSA 


continue DRAM cycle 


LCHLLLHXXL 


L H H L H 


L H L 


ACCESS5 


continue DRAM cycle new request 


LCLXXXXXXL 


H H L L H 


L H H 


, ACCESS6 


continue DRAM cycle 


LCHLLLHHHL 


H L L H L 


L H H 


» ACCESSl 


start DRAM cycle to other bank 


LCLXXXXXXL 


L L L H L 


L L H 


, ACCESS2 


continue DRAM cycle 


LCHXXXLLXL 


L H H H L 


L L H 


, ACCESS5 


continue DRAM cycle: it's read 


LCLXXXXXXL 


H H L H L 


L L L 


; ACCESS6 


continue DRAM cycle 


LCHLLLHHHL 


H L H H H 


L H X 


; IDLEl 


can't start same bank cycle 


LCLXXXXXXL 


H L H H H 


L H X 


; IDLE2 


wait for precharge 


LCHHXXXXHL 


H L L H L 


L H H 


; ACCESSl 


start DRAM cycle to same bank 


LCLXXXXXXL 


L L L H L 


L L H 


; ACCESS2 


continue DRAM cycle 


LCHHXXXHXL 


L L H H L 


L L H 


; ACCESS3 


continue DRAM cycle: it's write 


LCLXXXXXXL 


L H H H L 


L L H 


; ACCESS4 


continue DRAM cycle 


LCHLLLHXXL 


L H H H L 


L H H 


; ACCESS5 


continue DRAM cycle new request 


LCLXXXXXXL 


H H L H L 


L H L 


; ACCESS6 


continue DRAM cycle 


LCHLLLHXHL 


H L H H H 


L H X 


; IDLEl 


can't start same bank cycle 


LCLXXXXXXL 


H L H H H 


L H X 


; IDLE2 


wait for precharge 


LCHHXXXXHH 


H L L H L 


L H H 


; ACCESSl 


start DRAM cycle to same bank 


LCLXXXXXXH 


L L L H L 


L L H 


; ACCESS2 


continue DRAM cycle 


LCHHXXXHXH 


L L H H L 


L L H 


; ACCESS3 


continue DRAM cycle: it's write 


LCLXXXXXXH 


L H H H L 


L L H 


; ACCESS4 


continue DRAM cycle 


LCHLLLHXXH 


L H H H L 


L H H 


; ACCESS5 


continue DRAM cycle new request 


LCLXXXXXXH 


H H L H L 


H H L 


; ACCESS6 


continue DRAM cycle refresh req 


L C H L L L H X H H 


HLHHHHHX 


; IDLEl 


can't start: refresh pending 


LCLXXXXXXH 


L H L H H 


H H X 


; REFSTART2 wait for precharge | 


LCHHXXXXXH 


H L L L L 


H H X 


; ACCESSl 


start refresh cycle 


LCLXXXXXXH 


L L L L L 


H H X 


; ACCESS2 


continue refresh cycle 


LCHHXXXXXL 


L H H L L H H X 


; ACCESS5 


continue refresh cycle 


LCLXXXXXXL 


H H L L L 


H H X 


; ACCESS6 


continue refresh cycle 


LCHHXXXXXL 


H L H H H 


H H X 


; IDLEl 


can't start: refresh precharge 


LCLXXXXXXL 


H L H H H 


L H X 


; IDLE2 


wait for precharge 



Figure C-3. 2-CLK DRAM State PAL Equations (Cont'd.) 
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DRAM PAL DESCRIPTIONS 



L C H H X X X 


X 


L 




H 


L 


L 


L 


H 




H L; 


ACCESSl 


L C L X X X X 


X 


X 




L 


L 


L 


L 


H 




L L; 


ACCESS2 


L C H L L L r. 




X 




L 


H 


H 


L 


H 




H L; 


ACCESS5 


L C L X X X X 


X 


■?' 




H 


H 


L 


L 


H 




H H; 


ACCESS6 


L C H L L L H 


X 


H 




H 


L 


L 


H 


L 




H H; 


ACCESSl 


L C L X X X X 


X 


X 




L 


L 


L 


H 


L 




L H; 


ACCESS2 


L C H H X X X 


L 


X 




L 


H 


H 


H 


L 




L H; 


ACCESS5 


L C L X X X X 


X 


X 




H 


H 


L 


H 


L 




L L; 


ACCESS6 


L C H H X X X 


X 


X 




H 


L 


H 


H 


H 




L X; 


IDLEl 


L C L X X X X 


X 


X 


1 


H 


L 


H 


H 


H 




L X; 


IDLE2 


L C H H X X X 


X 


X 


h 


H 


L 


H 


H 


H 




L X; 


IDLEl 


L C L X X X X 


X 


X 


H 


H 


L 


H 


H 


H 


H 


L X; 


IDLE2 


L C H L L L H 


X 


H 


H 


H 


L 


H 


H 


H 


H 


H X; 


IDLEl 


L C L X X X X 


X 


X 


H 


L 


H 


L 


H 


H 


H 


H X; 


REFSTART2 


L C H H X X X 


X 


X 


H 


H 


L 


L 


L 


L 


H 


H X; 


ACCESSl 



start DRAM cycle 

continue DRAM cycle 

continue DRAM cycle: it's read 

continue DRAM cycle 

start DRAM cycle to other bank 

continue DRAM cycle 

continue DRAM cycle: it's read 

continue DRAM cycle 

no dram request pending 

wait for precharge 

no dram request pending 

refresh request sampled 

can't start: refresh pending 

refresh address set-up 

start refresh cycle 



DESCRIPTION 

*** NOTE - SOME VERSIONS OF PALASM WILL CRASH IF THE FILE IS TOO LONG *** 

*** IF YOURS DOES, DELETE THIS DESCRIPTION (FROM HERE TO END-OF-FILE) *** 

This PAL implements the main state machine of the DRAM controller. 
The state machine is described below. 



For brevity, the following keywords are used 



SELECT = (/CSO * /CSl 



/CS2 * CS3 * CLK) 

;chip selects and clock must be active to select 



SELECTED = (SELECT + DRAMSELECT) ;true if DRAM is now or has been selected 

STARTACCESS = (SELECTED * /MUXOE) ; start dram access cycle from idle 

The states are defined below and indicated by ROWSEL:Q1:QO:CLK. 

The 4-bit binary number following the state name represents these four signals. 



I state REFSTART2 



/RASO 


: = 


ON 


/RASl 


: = 


ON 


MUXOE 


: = 


MUXOE 



= = = = = = = = = = = = = = = = = = = = =:. = = = = = = = = = = = = = = = \ 

0101 ;cycle preceding refresh | 
;next cycle is first RAS for refresh] 



;maintain MUXOE state 



I 



I state IDLEl 



1010 



/RASO 
i /RASl 
I MUXOE 



OFF 
= OFF 
= RFRQ 



[MUXOE * RFRQ 
1 

;waiting for access or refresh | 

;both RAS's idle |<- 

I 
; sample refresh request | 



I 

|/(MUXOE * RFRQ) l/STARTACCESS 



/==== 



state IDLE2 = 1011 ;waiting for access or refresh 



/RASO 
I /RASl 
I A2REG 
I MUXOE 



:= (/A2 * STARTACCESS) 

= ( A2 * STARTACCESS) 

= A2 

= MUXOE 



; start access 

; sample A2 state j 
;maintain MUXOE statej 



I STARTACCESS 



always 



Figure C-3. 2-CLK DRAM State PAL Equations (Cont'd.) 
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state ACCESSl = 1000 ;first cycle of access or refresh |<--+ 



/RASO 
/RASl 
A2REG 
MUXOE 



= /A2REG + MUXOE ;RAS corresponding to A2 
= A2REG + MUXOE ;or refresh 1 

= A2REG ;maintain state of sampled A2| 
= MUXOE ;maintain MUXOE state |<- 

=/ 



I 



[always 



state ACCESS2 = 0001; second cycle of access or refresh | 
/RASO := /A2REG + MUXOE ;RAS corresponding to A2 | 
/RASl := A2REG + MUXOE ; or refresh |-- 

A2REG := A2REG ;maintain state of sampled A2J 
MUXOE := MUXOE ;maintain MUXOE state | 

I /DT%R + MUXOE 

|/(/DT%R + MUXOE) 

V 

state ACCESS3 = 0010 ; third cycle of access or refresh! 



/RASO 
/RASl 
A2REG 
MUXOE 



/A2REG 
:= A2REG 
:= A2REG 
:= MUXOE 



MUXOE ;RAS corresponding to A2 

MUXOE ;or refresh \ 

;maintain state of sampled A2| 

;maintain MUXOE state | 

============ ===================/ 



{always 

V 



/=============== 

state ACCESS4 



=\ 



/RASO 
/RASl 
A2REG 
MUXOE 



0111;fourth cycle of access or refresh! 



= /A2REG + MUXOE ;RAS corresponding to A2 ! 
= A2RE6 + MUXOE ;or refresh | 

= A2REG ;maintain state of sampled A2| 
= MUXOE ;maintain MUXOE state ! 
==========================/ 



I 
{always 

V 

state ACCESS5 =1110 ; fifth cycle of access or refresh! 




= /A2REG + 

= A2REG + 
= /A2REG 

= MUXOE + 



MUXOE ;RAS corresponding to A2 
MUXOE ;or refresh |<- 

; invert state of sampled A2 \ 
RFRQ ; sample refresh request | 

=/ 



I 



state ACCESS6 
/RASO 
/RASl 
A2REG 
MUXOE 



always! 

V 



(STARTACCESS 



(( A2 * A2REG) 
+(/A2 * /A2REG))) 

1101 ;sixth cycle of access or refresh! 
= /A2 * /A2REG * STARTACCESS; start next... ! 

= A2 * A2REG * STARTACCESS; interleave acces! + 

= A2REG ;maintain state of interleave AZJ 
= MUXOE ;maintain MUXOE state | 

/(STARTACCESS * (( A2 * A2REG) 1 

+ (/A2 * /A2REG)))-»- - 



Figure C-3. 2-CLK DRAM State PAL Equations (Cont'd.) 
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DRAM PAL DESCRIPTIONS 



Finally, the karnaugh maps for the following signals are: 



Q1\CLK 


00 


01 


11 


10 






v_ 












MUXOE 


00 1 




MUX 




MUX 


key: 




01 1 




MUX 


MUX 


M+R 


MUX = 


= MUXOE 


11 1 




MUX 






M+R = 


= MUXOE + RFRQ 


10 1 


MUX 




MUX 


RFR 


RFR = 


= RFRQ 


ROWSELXQO 














Q1\CLK 


00 


01 


11 


10 






v_ 












A2REG 


00 




A2R 




A2R 


key: 




01 




A2R 


A2R 


A2R 


A2; = 


= A2 


11 1 




A2R 






A2R - 


= A2REG 


10 1 


A2R 




A2; 


A2; 






ROWSELXQO 














QIXCLK 


00 


01 


11 


10 






X 












RAS signa 



00 I /AM AM /AM AM 

01 I ON ON /AM AM /AM AM 
U I /AI AI 

10 I /AM AM /AS AS OFFOFF 



key: [RAS0:RAS1] 

AM = A2REG + MUXOE 

AS = A2 * STARTACCESS 

AI = A2 * STARTACCESS * interleave 



ROWSELXQO 
QIXCLK 


00 


01 


11 


10 


00 1 

01 1 

11 1 
10 1 


0001 


OWIO 
1000 
lOiO 


Olio 
lOsO 


0111 
1101 

mMml 


ROWSELXQO 
QIXCLK 
X_ 


00 


01 


11 


10 


00 1 

01 1 
11 1 




OWIO 
1000 
lOiO 


Olio 


0111 
1101 


10 1 


0001 




lOsO 


mMml 


ROWSELXQO 
QIXCLK 


00 


01 


11 


10 


10 
11 
01 
00 


0001 


OWIO 
1000 
1010 


Olio 
lOsO 


0111 
1101 

mMml 



ROWSEL state circled 
key: [ROWSEL:Q1:QO:CLK] 
M = MUXOE * RFRQ 
S = STARTACCESS 
I = STARTACCESS * interleave 
W = W%R + MUXOE 



Ql state circled 



QO state circled 



Figure C-3. 2-CLK DRAM State PAL Equations (Cont'd.) 
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DRAM CONTROL PAL 

The DRAM Control PAL generates the majority of the control signals for the DRAM circuit. 
The inputs sample the W/R# and byte-enable outputs of the 80386 as well as status signals 
from the DRAM State PAL, The outputs generate the four CAS signals, two transceiver 
control signals, and the signals for the 80386 READY# and Next Address (NA#) logic. 
Table C-2 contains a description of the outputs and inputs. 

The equations for the 3-CLK DRAM Control PAL are shown in Figure C-4; those for the 
2-CLK DRAM Control PAL are shown in Figure C-5. A 16R8 PAL is needed to register 
the CAS signals internally. A 16R4 PAL is needed when external registers drive the CAS 
signals. For a 16-MHz system, B-series PAL speeds are required. 



REFRESH INTERVAL COUNTER PAL 

The Refresh Interval Counter PAL, which periodically generates refresh requests to the 
DRAM State PAL, operates as a counter decremented every CLK cycle. Once the counter 
reaches a preset value, it resets its value to 255 and activates its RFRQ (refresh request) 
output. This output remains active until both REPACK (refresh acknowledge) inputs are 
sampled simultaneously active. 

Setup and hold times for RFRQ to the DRAM State PAL are guaranteed even with a large 
CLK2-to-CLK skew because the Refresh Interval Counter PAL is clocked by the rising edge 
of CLK, and the RFRQ output is only sampled by the DRAM State PAL at the middle-of- 
phase CLK2 edge. However, the CLK2-to-CLK and output delays can add up so that the 
setup and hold times for the REPACK inputs are not met. Therefore, the REPACK inputs 
are activated for a minimum of four CLK2 periods to ensure deactivation of RFRQ. The 
exact CLK in which RFRQ is deactivated is not critical. 

Table C-3 shows the inputs and outputs of the Refresh Interval Counter PAL. Figure C-6 
shows its PAL equations. The same equations are used for both the 3-CLK and 2-CLK 
designs. A 20X10 PAL is used to implement this counter. For 16-MHz systems, A-series 
PAL speeds are sufficient. 



REFRESH ADDRESS COUNTER PAL 

The Refresh Address Counter PAL maintains the address of the next DRAM row to be 
refreshed. After every refresh cycle, the PAL increments this address. Table CA shows the 
inputs and outputs of the Refresh Address Counter PAL. 

PAL equations are shown in Figure C-7. Both the 3-CLK and the 2-CLK design use the 
same equations. Most DRAMs require only 8-bits or fewer for the refresh row address, so a 
16R8 PAL can be used. If necessary, 10 bits of row address can be provided using a 20X10 
PAL. For a system operating at any speed, standard-PAL speeds are sufficient. 
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Table C-2. DRAM Control PAL Pin Description 



PAL CONTROLS 




Name 


Connects From 


PAL Usage 




CLK2 


System CLK2 


PAL register clock 




OE 


Tied low 


Outputs always enabled 




PAL INPUTS 


Name 


Connects From 


PAL Usage 


Sampled 


CLK 


System CLK 


Indicates clock phase 


Every CLK2 


BEO# 
BE1# 
BE2# 
BE3# 


System Byte-Enables 


Used to enable the DRAM 
CAS signals corresponding 
to the active bytes 


Start-Of-Phase for 
internal reg. Every 
CLK2 with exter- 
nal reg 


W/R# 


System W/R# 


Select write/read 


Every CLK2 


ROWSEL 


DRAM STATE PAL 


Initiate DRAM access 


Middle-Of-Phase 


DISABLE 


DRAM STATE PAL 
MUXOE 


Disable controls during 
refresh 


Middle-Of-Phase 


PAL OUTPUTS 


Name 


Connects To 


PAL Usage 


Changes State 


CASO# 


DRAM Byte 


Controls DRAM CAS signals 

(Separate controls for writes 
to individual bytes) 


Start-Of-Phase for 
read active and 
read/write inactive 

Middle-Of-Phase 
for write active 


CAS1# 


DRAM Byte 1 


CAS2# 


DRAM Byte 2 


CAS3# 


DRAM Byte 3 


DEN# 


Transceiver 


Control xcvr enable 


Start-Of-Phase 


DT/R# 


Transceiver 


Control xcvr direction 


Any time DEN# 
off 


ROY 


System Ready Logic 


Control system ready 


Rise: Start-Phase 
Fall: Middle-Phase 


WC 


DRAM WE# and 
System NA# logic 


Stores PAL state used only 
in 3-CLK 


Rise: Start-Phase 
. Fall: Middle-Phase 


WE# 


DRAM WE# 


Control DRAM WE# used 
only in 2-CLK 


Rise: Start-Phase 
Fall: Middle-Phase 
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PAL16R8 PAL DESIGN SPECIFICATIONS 

PART NUMBER: 3-CLK DRAM CONTROL PAL 

DRAM CONTROL PAL OF INTERLEAVED DRAM CONTROLLER FOR 80386 SYSTEMS 

INTEL, SANTA CLARA, CALIFORNIA 

CLK2 CLK BED BEl BE2 BE3 W%R ROWSEL DISABLE GND 

OE CASO CASl DT%R DEN RDY WC CAS2 CAS3 VCC 



/CASO 



/CASl 



:= /ROWSEL * CLK * /DT%R * /DISABLE ;drop CAS on read 
+ /ROWSEL * WC * RDY * /CLK * /BEO ;drop on write 
+ /ROWSEL * /CASO ;inaintain throughout cycle 

;BEx can disappear after CAS drop 
;DISABLE must be maintained through last /ROWSEL * CLK 



:= /ROWSEL * CLK * /DT%R * /DISABLE 
+ /ROWSEL * WC * RDY * /CLK * /BEl 
+ /ROWSEL * /CASl 



/CAS2 := /ROWSEL * CLK * /DT%R * /DISABLE 
+ /ROWSEL * WC * RDY * /CLK * /BE2 
+ /ROWSEL * /CAS2 



/CAS3 

/DT%R 

/DEN : 
/WC : = 

/RDY := 



= /ROWSEL * CLK * /DT%R * /DISABLE 
+ /ROWSEL * WC * RDY * /CLK * /BE3 
+ /ROWSEL * /CAS3 



;drop CAS on read 

;drop on write 

;maintain throughout cycle 

;drop CAS on read 

;drop on write 

;maintain throughout cycle 

;drop CAS on read 

;drop on write 

;maintain throughout cycle 



= ROWSEL * DEN * /W%R 
+ /ROWSEL * /DT%R 
+ /DEN * /DT%R 



; sample W%R when /ROWSEL * DEN 
-.otherwise: maintain state 



= CLK * /ROWSEL 
+ /CLK * /DEN 

DISABLE 
+ ROWSEL 
+ /RDY 
+ /WC * /CLK 



WC 
/RDY 



CLK 
/DEN 



/DISABLE ;when CLK: sample ROWSEL 
;otherwise: maintain state 



keep low if DISABLE 
or /ROWSEL 
or /RDY 
or already low * /CLK 

;drop RDY 
;maintain RDY 



Figure C-4. 3-CLK DRAM Control PAL Equations 
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FUNCTION TABLE 

OE CLK2 CLK BEO BEl BE2 BE3 W%R ROWSEL DISABLE ; inputs 
CASO CASl CAS2 CAS3 DT%R DEN RDY WC ; outputs 



;0E 



CLK2 
CLK 
I BEO 



I 



BEl 
BE2 
I BE3 
I I W%R 
I I I ROWSEL 
MM DISABLE 
Mill 



CASO 
CASl 
CAS2 



CASS 
I DT%R 
I I DEN 



M I I RDY 

I II I I WC 

I II II I 



COMMENTS 



L C H X X 


X 


X 


X H 




X 


X 


X 


X 




H 


X 


L ; 


initialize to IDLE 


L C L X X 


X 


X 


L 


H 




H 


H 


H 


H 




H 


H 


L ; 


IDLE: DT%R tracking W%R 


L C H X X 


X 


X 


H 


H 




H 


H 


H 


H 




H 


H 


L ; 


IDLE: DT%R tracking W%R 


L C L X X 


X 


X 


L 


H 




H 


H 


H 


H 




H 


H 


L ; 


IDLE: DT%R tracking W%R 


L C H X X 


X 


X 


X 


L 




L 


L 


L 


L 




L 


H 


H • 


begin read: assert all CAS's 


L C L X X 


X 


X 


X 


L 




L 


L 


L 


L 




L 


H 


H • 


continue read: 


L C H X X 


X 


X 


X 


L 




L 


L 


L 


L 




L 


L 


H 


continue read: RDY active 


L C L X X 


X 


X 


X 


L 




L 


L 


L 


L 




L 


L 


L • 


last read cycle 


L C H X X 


X 


X 


X 


H 




H 


H 


H 


H 




H 


L 


L 


CAS's and DEN rise 


L C L X X 


X 


X 


H 


H 




H 


H 


H 


H 


H 


H 


H 


L 


DT%R and RDY rises 


L C H X X 


X 


X X 


L 




H 


H 


H 


H 


H 


L 


H 


H 


begin write: assert DEN and WE 


L C L H L 


L 


H 


X 


L 




H 


L 


L 


H 


H 


L 


H 


H 


continue write: assert valid CAS's 


L C H X X 


X 


X 


X 


L 




H 


L 


L 


H 


H 


L 


L 


H 


continue write: RDY active 


L C L X X 


X 


X 


X 


L 




H 


L 


L 


H 


H 


L 


L 


L 


continue write: 


L C H X X 


X 


X 


X 


H 




H 


H 


H 


H 


H 


H 


L 


L 


CAS's and DEN rise 


L C L X X 


X 


X 


L 


H 




H 


H 


H 


H 




H 


H 


L 


RDY rises 


L C H X X 


X 


X 


X 


L 




L 


L 


L 


L 




L 


H 


H 


begin read: assert all CAS's 


L C L X X 


X 


X 


X 


L 




L 


L 


L 


L 




L 


H 


H 


, continue read: 


L G H X X 


X X 


X 


L 




L 


L 


L 


L 




L 


L 


H 


continue read: RDY active 


L C L X X 


X 


X 


X 


L 




L 


L 


L 


L 




L 


L 


L 


, last read cycle 


L C H X X 


X 


X 


X 


H 




H 


H 


H 


H 




H 


L 


L 


, CAS's and DEN rise 


L C L X X 


X 


X 


X 


H 




H 


H 


H 


H 


X 


H 


H 


L 


, RDY rises 


L C H X X 


X 


X 


X 


L 


H 


H 


H 


H 


H 


X 


H 


H 


L 


, begin refresh 


L C L X X 


X 


X 


X 


L 


H 


H 


H 


H 


H 


X 


H 


H 


L 


, continue refresh 


L C H X X 


X 


X 


X 


L 


H 


H 


H 


H 


H 


X 


H 


H 


L 


continue refresh 


L C L X X 


X 


X 


X 


L 


L 


H 


H 


H 


H 


X 


H 


H 


L 


, last refresh cycle 


L C H X X 


X 


X 


X 


H 


L 


H 


H 


H 


H 


X 


H 


H 


L 


, IDLE 


L C L X X 


X 


X 


X 


H 


L 


H 


H 


H 


H 


X 


H 


H 


L 


, IDLE 



DESCRIPTION 

This PAL implements most of the control signals of the DRAM controller. 



Figure C-4. 3-CLK DRAM Control PAL Equations (Cont'd.) 
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PAL16R4 PAL DESIGN SPECIFICATIONS 

PART NUMBER: 2-CLK DRAM CONTROL PAL 

DRAM CONTROL PAL OF INTERLEAVED DRAM CONTROLLER FOR 80386 SYSTEMS 

INTEL, SANTA CLARA, CALIFORNIA 

CLK2 CLK BED BEl BE2 BE3 W%R ROWSEL DISABLE GND 

OE CASO CASl DT%R DEN RDY WE CAS2 CASS VCC 

/CASO = /ROWSEL * /DT%R * CLK * /DISABLE ;drop CAS on read 

+ /ROWSEL * /DT%R * /DEN ;maintain CAS on read 
+ /ROWSEL * /DEN * /BEO * /DISABLE -.activate CAS on write 

;BEx must be maintained throughout 
;DISABLE must be maintained through last /ROWSEL * CLK 

/CASl = /ROWSEL * /DT%R * CLK * /DISABLE ;drop CAS on read 

+ /ROWSEL * /DT%R * /DEN ^maintain CAS on read 
+ /ROWSEL * /DEN * /BEl * /DISABLE ; activate CAS on write 

/CAS2 = /ROWSEL * /DT%R * CLK * /DISABLE ;drop CAS on read 

+ /ROWSEL * /DT%R * /DEN ;maintain CAS on read 
+ /ROWSEL * /DEN * /BE2 * /DISABLE ;activate CAS on write 

/CAS3 = /ROWSEL * /DT%R * CLK * /DISABLE ;drop CAS on read 

+ /ROWSEL * /DT%R * /DEN ;maintain CAS on read 

+ /ROWSEL * /DEN * /BE3 * /DISABLE ;activate CAS on write 

/DT%R := ROWSEL * DEN * /W%R ; sample W%R when /ROWSEL * DEN 
+ /ROWSEL * /DT%R ; otherwise: maintain state 

+ /DEN * /DT%R 

/DEN := CLK * /ROWSEL * /DISABLE ;when CLK: sample ROWSEL 
+ /CLK * /DEN ;otherwise: maintain state 

/WE := /ROWSEL * DT%R * RDY * /DISABLE ;only drops for writes 

/RDY := /ROWSEL * /DT%R * /DISABLE * CLK ;drop RDY immediately for read 
+ /WE * CLK ;drop RDY later for write 

+ /RDY * /DEN ;maintain RDY 



Figure C-5. 2-CLK DRAM Control PAL Equations 
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FUNCTION TABLE 

OE CLK2 CLK BEO BEl BE2 BE3 W%R ROWSEL DISABLE ; inputs 
CASO CASl CAS2 GAS3 DT%R DEN RDY WE ;outputs 



;0E 

;| CLK2 
CLK 



;i I M 

;l I I 

;l I I 

;l I I 

;l I I 

;l I I 



BEO 
BEl 
BE2 



CASO 
CAS I 
I CAS2 



BE3 

I W%R 
I ROWSEL 
I I DISABLE 

■ I I 



I 



I 

I . 
I I 



CASS 
I DT%R 
I I DEN 



I RDY 
I I WE 

I I I 



COMMENTS 



L C H 


X X X X X 


H 




X X X X 


X H 


X H ; 


initialize to IDLE 


L C L 


X X X X L 


H 




H H H H 


L H 


H 


H ; 


IDLE: DT%R tracking W%R 


L C H 


X X X X H 


H 




H H H H 


H H 


H 


H , 


IDLE: DT%R tracking W%R 


L C L 


X X X X L 


H 




H H H H 


L H H 


H 


IDLE: DT%R tracking W%R 


L C H X X X X X 


L 




L L L L 


L L 


L 


H 


begin read: assert all CAS's 


L C L 


X X X X X 


L 




L L L L 


L L 


L 


H 


last read cycle 


L C H 


X X X X X 


H 




H H H H 


L H 


L 


H 


CAS's and DEN rise 


L C L 


X X X X H 


H 




H H H H 


H H 


H 


H 


DT%R and RDY rises 


L C H 


H L L H X 


L 




H L L H 


H L 


H 


L 


begin write: assert DEN and WE 


L C L 


H L L H X 


L 




H L L H 


H L 


H 


L 


continue write: assert valid CAS*s 


L C H 


H L L H X 


L 




H L L H 


H L 


L 


L 


continue write: RDY active 


L C L 


H L L H X 


L 




H L L H 


H L 


L 


H 


continue write: 


L C H 


X X X X X 


H 




H H H H 


H H 


L 


H 


CAS's and DEN rise 


L C L 


X X X X L 


H 




H H H H 


L H 


H 


H 


RDY rises 


L C H 


X X X X X 


L 




L L L L 


L L 


L 


H 


begin read: assert all CAS's 


L C L 


X X X X X 


L 




L L L L 


L L 


L 


H 


last read cycle 


L C H 


X X X X X 


H 




H H H H 


L H 


L 


H 


CAS's and DEN rise 


L C L 


X X X X X 


H 




H H H H 


X H 


H 


H 


RDY rises 


L C H 


X X X X X 


L 


H 


H H H H 


X H 


H 


H 


begin refresh 


L C L 


X X X X X 


L 


H 


H H H H 


X H 


H 


H 


continue refresh 


L C H 


X X X X X 


L 


H 


H H H H 


X H 


H 


H 


continue refresh 


L C L 


X X X X X 


L 


L 


H H H H 


X H 


H 


H 


last refresh cycle 


L C H 


X X X X X 


H 


L 


H H H H 


X H 


H 


H 


, IDLE 


L C L 


X X X X X 


H 


L 


H H H H 


X H 


H 


H 


IDLE 



DESCRIPTION 

This PAL implements most of the control signals of the DRAM controller. 



Figure C-5. 2-CLK DRAM Control PAL Equations (Cont'd.) 
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Table C-3. Refresh Interval Counter PAL Pin Description 



PAL CONTROLS 




Name 


Connects From 


PAL Usage 




CLK 


Systems CLK 


PAL register clock 




OE 


Tied low 


Outputs always 
enabled 




PAL INPUTS 


Name 


Connects From 


PAL Usage 


Sampled 


REFACKO# 
REFACK1# 


DRAM RASO# 
DRAMRAS1# 


Indicates when refresh 
starts: turns off RFRQ 


Every CLK that 
RFRQ is active 


NCO 
NC1 
NC2 
NC3 
NC4 
NC5 
NC6 
NC7 


Not connected 


Not used 


Never 


PAL OUTPUTS 


Name 


Connects To 


PAL Usage 


Changes State 


RFRQ 


DRAM STATE RFRQ 


Latch refresh request 


Any CLK 


QO 
Q1 
Q2 
Q3 
Q4 
Q5 
Q6 
Q7 
Q8 


Not connected 


Implements up to 9-bit 
modulo counter 


Any CLK 
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PAL20X10 














PAL DESIGN SPECIFICATIONS 


PART NUMBER 


: 16 MHz 


REFRESH INTERVAL COUNTER 1 


'AL 


REFRESH 


INTERVAL PAL OF 


INTERLEAVED DRAM CONTROLLER FOR 80386 SYSTEMS 


INTEL, SANTA CLARA, 


CALIFORNIA 








CLK REFACKO REFACKl NC NC 


NC NC NC NC 


NC NC GND 


OE RFRQ 


NC QO Ql Q2 


Q3 


Q4 Q5 


Q6 Q7 


VCC 


/RFRQ := 




/RFRQ 


* Q7 


* Q6 * 


Q5 * 


Q4 * Q3 * 


Q2 * Ql * QO ;raise at 255 






+ RFRQ 


* /REFACKO 


* /REFACKl 


; clear when both ACKs low 




: + : 


/RFRQ 










;else: don't change state 


/QO :- 




/QO 








;least-significant bit of counter | 






+ /Q7 * 


/Q6 


*/Q5 


*/Q4 


*/Q3 


;set at 7 or less 




: + : 


VCC 










;else decrement 


/Ql : = 




/Ql 
















+ /Q7 * 


/Q6 


*/Q5 


*/Q4 


*/Q3 


;set at 7 or less 




: + : 


/Q7 * 
+ /Q0 


/Q6 


*/Q5 


* /Q4 


*/Q3 


;set at 7 or less 
;else decrement 


/Q2 : = 




/Q2 
















+ /Q7 * 


/Q6 


*/Q5 


*/Q4 


*/Q3 


;set at 7 or less 




: + : 


/Q7 * 
+ /Q1 * 


/Q6 
/QO 


*/Q5 


*/Q4 


*/Q3 


;set at 7 or less 
;else decrement 


/Q3 : = 




/Q3 
















+ /Q7 * 


/Q6 


*/Q5 


*/Q4 


*/Q3 


;set at 7 or less 




: + : 


/Q7 * 


/Q6 


*/Q5 


*/Q4 


*/Q3 


;set at 7 or less 






+ /Q2 * 


/Ql 


*/Q0 






;else decrement 


/Q4 : = 




/Q4 
















+ /Q7 * 


/Q6 


*/Q5 


*/Q4 


* /Q3 


;set at 7 or less 




: + : 


/Q7 * 


/Q6 


* /Q5 


*/Q4 


*/Q3 


;set at 7 or less 






+ /Q3 * 


/Q2 


*/Ql 


*/Q0 




;else decrement 


/Q5 : = 




/Q5 
















+ /Q7 * 


/Q6 


*/Q5 


*/Q4 


*/Q3 


;set at 7 or less 




: + : 


/Q7 * 


/Q6 


*/Q5 


*/Q4 


* /Q3 


;set at 7 or less 






+ /Q4 * 


/Q3 


*/Q2 


*/Ql 


* /QO 


;else decrement 


/Q6 : = 




/Q5 
















+ /Q7 * 


/Q6 


*/Q5 


*/Q4 


*/Q3 


;set at 7 or less 




: + : 


/Q7 * 


/Q6 


*/Q5 


*/Q4 


*/Q3 


;set at 7 or less 






+ /Q5 * 


/Q4 


* /Q3 


*/Q2 


* /Ql * /QO ;else decrement 1 


/Q7 : = 




/Q7 








;most 


-significant bit of counter 






+ /Q7 * 


/Q6 


*/Q5 


*/Q4 


*/Q3 


;set at 7 or less 




: + : 


/Q7 * 


/Q6 


*/Q5 


*/Q4 


*/Q3 


;set at 7 or less 






+ /Q6 * 


/Q5 


*/Q4 


*/Q3 


* /Q2 * /Ql * /QO ;else decrement 



Figure C-6. Refresh Interval Counter PAL Equations 
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F 

C 
F 


UNCTION 

)E CLK 
IFRQ Q7 

OE 
1 CLK 

1 1 


TABLE 

REFACKO REFACKl ; inputs 
Q6 Q5 Q4 Q3 Q2 Ql QO ;outputs 

Q7 

1 Q6 

1 1 Q5 

1 1 1 Q4 

1 1 M Q3 
REFACKO 1 1 1 1 1 Q2 
1 REFACKl 1 1 1 1 1 1 Ql 

I 1 RFRQ 1 1 1 1 1 1 i QO 

II 1 M 1 1 1 II 1 COMMENTS 




L C 
L C 
L C 
L C 
L C 
L C 
L C 
L C 
L C 
L C 
L C 


HX H LLLLHLHH; initial ize{ignore errors on vector) 

XH H LLLLHLHL; decrement 

L L L LLLLHLLH; decrement 

XX L LLLLHLLL; decrement 

XX L LLLLLHHH; decrement to 7 

XX L HHHHHHHH; reset to 255 

XX H HHHHHHHL; decrement, activate RFRQ 

HX H HHHHHHLH; decrement, sample REFACKs 

XH H HHHHHHLL; decrement, sample REFACKs 

LL L HHHHHLHH; decrement, both REFACKs: clear RFRQ 

XX L HHHHHLHL; decrement 




DESCRIPTION 

This PAL implements the counter to determine when distributed 
refresh cycles should be run. This counter counts intervals of 249 
clocks which is just under 15 uS at 15 MHz. 

The counter counts backwards from 255 to 7. The clock after the 
counter reaches 7, the counter is set to 255 and will then continues 
to decrement. Also when 7 is hit, RFRQ is activated until both 
REFACKO and REFACKl are simultaneously sampled low. 



Figure C-6. Refresh Interval Counter PAL Equations (Cont'd.) 
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Table C-4. Refresh Address Counter PAL Pin Description 



PAL CONTROLS 




Name 


Connects From 


PAL Usage 




CLOCK 


RFRQ & MUXOE# 


PAL register clock 




OE 


RFRQ & MUXOE# 


outputs enable on refresh 




PAL INPUTS 


Name 


Connects From 


PAL Usage 


Sampled 


NCO 
NC1 
NC2 
NC3 
NC4 
NC5 
NC6 
NC7 


Not connected 


Not used 


Never 


PAL OUTPUTS 


Name 


Connects To 


PAL Usage 


Changes State 


QO 
Q1 
Q2 
Q3 
Q4 
Q5 
Q6 
Q7 


Muxed Addr 
Muxed Addr 1 
Muxed Addr 2 
Muxed Addr 3 
Muxed Addr 4 
Muxed Addr 5 
Muxed Addr 6 
Muxed Addr 7 


Implements 8-bit counter 


Any Clock 



C-22 



Intel 



DRAM PAL DESCRIPTIONS 



PAL16R8 




PAL DESIGN SPECIFICATIONS 


PART NUMBER: REFRESH ADDRESS COUNTER PAL 1 


• REFRESH 


ADDRESS PAL 


OF INTERLEAVED DRAM CONTROLLER FOR 80386 SYSTEMS 


INTEL, 


SANTA CLARA, 


CALIFORNIA 


CLOCK 


NC NC NC 


NC NC NC NC NC GND 


OE AO 


Al A2 A3 


A4 A5 A6 A7 VCC 


/AO : = 


AO 


;1east significant bit of 8-bit counter 


/Al : = 


Al * AO 
+/A1 */A0 




/A2 : = 


A2 * Al * 
+/A2 */Al 
+/A2 */A0 


AO 


/A3 : = 


A3 * A2 * 
+/A3 */A2 
+/A3 */Al 
+/A3 */A0 


Al * AO 


/A4 : = 


A4 * A3 * 
+/A4 */A3 
+/A4 */A2 
+/A4 */Al 
+/A4 */A0 


A2 * Al * AO 


/A5 : = 


A5 * A4 * 
+/A5 */A4 
+/A5 VA3 
+/A5 */A2 
+/A5 */Al 
+/A5 */A0 


A3 * A2 * Al * AO 


/A6 : = 


A6 * A5 * 
+/A6 */A5 
+/A6 */A4 
+/A6 */A3 
+/A5 */A2 
+/A6 */Al 
+/A6 */A0 


A4 * A3 * A2 * Al * AO 


/A7 : = 


A7 * A6 * 
+/A7 */A6 
+/A7 */A5 
+/A7 VA4 
+/A7 */A3 
+/A7 */A2 
+/A7 */Al 
+/A7 */A0 


A5 * A4 * A3 * A2 * Al * AO;inost-significant bit of counter 



Figure C-7. Refresh Address Counter PAL Equations 
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FUNCTION TABLE 



OE CLOCK 

A7 A6 A5 A4 A3 A2 Al AG 



;inputs 
;outputs 



A7 



OE 

I CLOCK 

I I 



A6 



A5 



A4 



A3 
I A2 
I I Al 
I I I AG 
i I I I 



COMMENTS 



HHHHHHHH 
L L L L L L L L 



H H 



L L 
L L 
L L 
L H 
Z Z 



initialize (ignore any errors on this vector) 

increment 

increment 

increment 

increment 

increment 

high-impedence state 



DESCRIPTION 

This PAL implements a simple 8-bit counter which 
generate the refresh row address by the DRAM controller. 



is used to 



Figure C-7. Refresh Address Counter PAL Equations (Cont'd.) 
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TIMING PARAMETERS 

Figure C-8 shows the timing of signals for DRAM read and write cycles. Table C-5 displays 
the worst-case timing parameters for six DRAM circuits, each of which uses a different type 
of DRAM. 
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READ-1 REAO-2 READ-3 



WRlTE-1 WRITE-2 WRITE-3 



I ti I ti I ti I li I ti I U 'BAK2BAK .^ ti | ti | ti | ti 

U IfloWAIT J 



I ., I I ., I I ., 

r twRlWAIT •^ •BAK2BAK H 



IH 



M 



IH 



iQ| |Q 



|o| |Q 



I ICRP I* «RCO- 



I ICRP p 



-«RSH(n)_ 

-tcAs(R)- 



J V- 

— ICBP 4*- 



I" 



h 



J V 



_y V. 

|w|*«WRP*| 

J 



A_ 



|-- <e + 'mux —j»- USR-fcU tRAH — 



.Ash 






U U + tMUX J 



- y, ROW ~Y ~ 



xx: 



|*-'CAA-> 



-c 



J c 



U — IXCVR — 4-" '21 H U 4-txCVR L— tX— J 

I l. — fel — ^ ,„_l^ I 
{ ) CZI 



Utl2-J«-txcVR-»j 



> 
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Figure C-8. DRAM Circuit Timing Diagram 
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TIMING PARA 


METERS 




























Chip Symbol 


10 Description 


From 




To 




Min 


Max 


Min 


Max 


Min 


Max 


Min 


Max 


Min 


Max 


Nin Max 














51C64-8 


51C64-10 


51C25«-12 


51C256-15 


2164-15 


51C256-20 


82384 t1 


CLK2 period 


CLK2 
CLK2 
CLIC2 
CLK2 
CLK2 
CLK2 
CLK2 
CLK2 
CLIC2 
CLIC2 
CLK2 
CLK2 
CLK2 
CLK2 
CLK2 




CLK2 
CLK2 
CLK2 
CLK2 
CLK2 
CLK2 
CLK2 
CLK2 
CLIC2 
CLIC2 
CLK2 
CLK2 
CLK2 
CLIC2 
CLIC2 




31 


32 


31 


32 


40 


42 


31 


32 


31 


32 


40 42 


82384 trdWAIT 


CLKperiod(s) rd WaitState 


CLK2 




CLIC2 






















62 


64 


62 


64 


80 84 


82384 twrtWAH 


CLKpertod(s) wt WaitState 


CLK2 




CLK2 




62 


64 


62 


64 


80 


84 


62 


64 


62 


64 


80 84 


62384 tBAK2BAK CLKperiod(s) back- to-back 


CLK2 




CLK2 




62 


64 


62 


64 


160 


168 


124 


128 


124 


128 


160 168 






CLIC2 




CLK2 


























386 tt2 


write data out-detay 


CLK2 
CLK2 


/ 386 Oata< 
/ 386 Oata> 


1 


50 


1 


50 


1 


50 


1 


50 


1 


50 


1 50 


386 • t21 


read data set-up 


386 Oata< 


CLK2 


/ 





10 





10 





10 





10 





10 


10 


386 t22 


read data hold 


CLKZ 


/ 386 Oata> 


2 


999 


2 


999 


2 


999 


2 


999 


2 


999 


2 999 


386+MUX t6*tMU)( 


addr fr 386 thru LatchMux 


CLK2 
CL« 




row< 
row< 


3 


46 


3 


46 


3 


46 


3 


46 


3 


46 


3 46 


PAL P 


clock to PAL outputs 


CLK2 
CLK2 
CLK2 
CLIC2 
CLK2 




ROW Sel\ 
Row Sel/ 
Row Sel\ 
Row Sel/ 
Row Sel\ 





12 





12 





12 





12 





12 


12 


PALorfiEG Q 


clock to PAL or REG outpt 


CLIC2 
CLK2 
CLK2 
CLK2 
CLK2 




RAS# 
RAS# 
RAS# 
RAS# 
RAS# 







12 





12 


n 


12 





12 


4 


10 


12 


Register R 


clock to register output 


CLIC2 
CLK2 
CLK2 
CLK2 
CLK2 
CLK2 




CAS* 
CAS« 
CAS# 
CAS# 
CAS# 
CASI!/ 







12 





12 





12 





12 


4 


10 


12 


PAL+NANO U 


pal and write logic delay 


CLK2 
CLK2 
CLK2 




UEtt 
WEty 
UEU 




2 


18 


2 


18 


2 


18 


2 


18 


2 


18 


2 18 


Transcvr tXCVR 


transcvr prop in-to-out 


rd dat 


a< 


386 Data< 


2 


7 








2 


7 


2 


7 


2 


7 


2 7 






Drarrt)ata> 


386 Data> 




























386 Oat 


a< 


wrt dat 


a< 




























386 Dat 


a> 


DranC)ata> 

























Table C-5. DRAM Circuit Timing Parameters 
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TIMING PARANETE 


R S 


















Chip 


Symbol 


10 Description 


From 




To 




Hin Max 
5tC64-8 


Hin Max 
51C64-10 


Min Hax 
51C256-12 


Hin Max 
51C256-15 


Hin Hax 
2164-15 


Hin Max 
51C256-20 


DRAH 


tRAS 


I RAS# pulse width 


RAS« 
RAS« 




RAS« 
RAS# 




80 9999 


100 9999 


120 9999 


150 9999 


150 9999 


200 9999 


DRAM 


tRC 


1 random read/write cycle 


RAS« 

RAS« 




RAS# 
RAS« 




140 9999 


160 9999 


200 9999 


245 9999 


260 9999 


315 9999 


ORAM 


tRP 


I RAS# precharge time 


RASHf 
RAS« 




RAS« 
RAS# 




50 9999 


50 9999 


70 9999 


85 9999 


100 9999 


105 9999 


DRAH 


tCSH 


I CAS# hold time 


RAS« 
RAS# 




CA5# 
CAS# 




80 9999 


100 9999 


120 9999 


150 9999 


150 9999 


200 9999 


DRAH 


tCAS(R) 


I CAS# pulse width(rd cycl) 


CAS# 




CAS« 




15 9999 


20 9999 


25 9999 


30 9999 


85 9999 


35 9999 


DRAH 


tCA5(W) 


1 CAS# pulse width(urt eye) 


CAS# 




CAS« 




25 9999 


30 9999 


25 9999 


30 9999 




35 9999 


DRAH 


tWRP 


1 write to RAS« precharge 


UE# 
WE« 




RAS« 
RAS# 




-30 9999 


-30 9999 


10 9999 


10 9999 


-30 9999 


10 9999 


DRAM 


tRUH 


1 RAS« to write hold time 


RAS# 




WE« 




9999 


9999 


15 9999 


20 9999 


9999 


25 9999 


DRAH 


tASR 


I row address set-up time 


roM< 
row< 


RAS# 
RAS« 




9999 


9999 


9999 


9999 


09999 


9999 


DRAM 


tRAH 


I row address hold time 


RAS« 
RAS« 




colunn< 
colunn< 


15 9999 


15 9999 


15 9999 


20 9999 


20 9999 


25 9999 


DRAM 


tCP 


1 CAS# precharge 


CAS# 
CAS« 




CAS# 

CAS# 




10 9999 


10 9999 


10 9999 


10 9999 


25 9999 


10 9999 


DRAH 


tCRP 


t CAS» to RAS# precharge 


CASi 

CAS« 
CAS« 




RAS« 
RAS« 
RAS# 




-20 9999 


-20 9999 


-20 9999 


•20 9999 


-20 9999 


-20 9999 


DRAM 


« tRCD 


I RAS# to CAS« delay 


RAS« 
ftAS« 




CAS# 
CAS« 




30 9999 


30 9999 


30 9999 


35 9999 


30 9999 


40 9999 


DRAH 


tASC 


I column address set-up 


colunn< 

coluwi< 


CAS# 
CAS# 




9999 


9999 


5 9999 


5 9999 


09999 


59999 


DRAM 


tCAH 


1 column address hold 


CAS« 
CAS# 


\ DramAddr< 
\ DramAddr< 


10 9999 


10 9999 


15 9999 


20 9999 


25 9999 


25 9999 


DRAM 


tAR 


I colunn addr hold fr RAS« 


RAS# 
RAS« 


V OramAddr< 
\ DramAddr< 


40 9999 


40 9999 


60 9999 


70 9999 


90 9999 


80 9999 


DRAM 


* tow 


1 output buffer turn on 


CAS« 


\ 


rd data< 


20 9999 


20 9999 


25 9999 


30 9999 


85 9999 


35 9999 


DRAM 


* tOFF 


1 output buffer turn off 


CAS« 


/ wrt data< 


20 9999 


20 9999 


20 9999 


25 9999 


30 9999 


30 9999 


DRAM 


• tRAC 


1 access time from RAS# 


RAS« 


\ 


rd data< 


80 9999 


100 9999 


120 9999 


150 9999 


150 9999 


200 9999 


DRAM 


* tCAC 


1 access time from CAS# 


CAS# 


\ 


rd data< 


20 9999 


20 9999 


25 9999 


30 9999 


85 9999 


35 9999 


DRAH 


• tCAA 


i access time fr colunn adr 


colunn< 


rd data< 


45 9999 


55 9999 


55 9999 


70 9999 


85 9999 


90 9999 


DRAH 


tRSH(R) 


1 RAS« hold time (rd cycle) 


CAS# 


\ 


RAS« 


/ 


10 9999 


10 9999 


10 9999 


10 9999 


85 9999 


10 9999 


DRAM 


tRCS 


I read command set-up time 


RAS# 


\ 


rd data< 


09999 


9999 


09999 


9999 


09999 


09999 


DRAM 


tCAR 


I column address to RAS# 


COlUTK 


RAS« 




45 9999 


55 9999 


55 9999 


70 9999 


85 9999 


90 9999 


DRAM 


tRCH 


1 read com hold ref to CAS# 


CAS# 




UE« 




9999 


9999 


9999 


9999 


5 9999 


9999 


DRAM 


tRRH 


I read com hold ref to RAS# 


RAS0 




WE» 




10 9999 


10 9999 


10 9999 


10 9999 


20 9999 


10 9999 


DRAH 


tRSH(U) 


I RAS# hold time (wrt cycl) 


CAS# 




RAS# 




35 9999 


35 9999 


25 9999 


30 9999 


85 9999 


35 9999 


ORAM 


tRWL 


I write command to RAS« 


UE# 




RAS« 




25 9999 


30 9999 


25 9999 


30 9999 


40 9999 


35 9999 


DRAH 


tCWL 


I write comnand to CAS# 


UE« 




CAS» 




25 9999 


30 9999 


25 9999 


30 9999 


40 9999 


35 9999 


DRAH 


tWP 


I write comnand pulse width 


UE# 




UE« 




20 9999 


20 9999 


20 9999 


25 9999 


30 9999 


30 9999 


DRAH 


twcs 


1 write command set-up time 


WE* 




CAS« 




9999 


9999 


9999 


9999 


-10 9999 


9999 


DRAH 


tWCH 


] write comnand hold time 


CAS« 




WE# 




25 9999 


30 9999 


25 9999 


30 9999 


30 9999 


35 9999 


DRAH 


tos 


I data-in set-up time 


wrt data< 


CAS« 




9999 


9999 


9999 


9999 


9999 


9999 


DRAH 


tDH 


I data-in hold time 


CAS# 


\ OrafnData> 


20 9999 


20 9999 


20 9999 


25 9999 


30 9999 


30 9999 



Table C-5. DRAM Circuit Timing Parameters (Cont'd.) 





386 DRAH Controller 






















TIHING CALCULAT 


1 


N S 
















Chip 


Symbol 10 Description 


From 




To 




Hin Hax 
51C64-8 


Hin Hax 
51C64-10 


Hin Hax 
51C256-12 


Hin Hax 
51C256-15 


Hin Hax 
2164-15 


Hin Hax 
51C256-20 


ORAM 
♦Q 


tRAS RAS# pulse width 
♦trdWAIT +t1 +t1 +11 


♦t1 


-Q 






80 9999 


100 9999 


120 9999 


150 9999 


150 9999 


200 9999 


+Q 


♦twrtUAIT+tl ♦tl +t1 


RAS« 
+t1 


\ 

-Q 


RAS« 




112 140 


112 140 


148 180 


174 204 


180 198 


228 264 






RA5« 


\ 


RAS« 




174 204 


174 204 


228 264 


174 204 


180 198 


228 264 


ORAM 
♦Q 


tRC random read/urfte cycle 
♦t8AK2BAK+trdWAIT *t\ +11 


♦ t1 


+t1 







140 9999 


160 9999 


200 9999 


245 9999 


260 9999 


315 9999 


♦Q 


+ tBAK2BAK+turtUAlUt1 *t^ 


RAS# 
♦t1 


\ 
♦t1 


RAS# 


Q 


174 204 


174 204 


308 348 


298 332 


304 326 


388 432 






RAS« 


\ 


RAS# 




236 268 


236 268 


388 432 


298 332 


304 326 


388 432 


DRAH 

♦Q 

♦Q 


tRP RAS# precharge time 

->-tBAK2BAK-Q 

-^tBAK2BAK-Q 


RAS« 
RAS« 


/ 

/ 


RAS# 
RAS# 




50 9999 
50 76 
50 76 


50 9999 
50 76 
50 76 


70 9999 
148 180 
148 180 


85 9999 
112 140 
112 140 


100 9999 
118 134 
118 134 


105 9999 
148 180 
148 180 


DRAH 

♦ R 


tCSH CAS# hold tine 
♦trdyAIT +11 *t1 +tl 


♦t1 


-0 






80 9999 


100 9999 


120 9999 


150 9999 


150 9999 


200 9999 


♦ R 


+tMrtWAIT*t1 +11 *t\ 


RASi 
♦t1 


\ 
-0 


CAS« 




112 140 


112 140 


148 180 


174 204 


180 198 


228 264 






RAS« 


\ 


CAS# 




174 204 


174 204 


228 264 


174 204 


180 198 


228 264 


DRAM 
♦ R 


tCAS(R) CAS# pulse width(rd cycl) 
♦trdUAIT +11 +11 -R 


CAS# 


\ 


CAS« 




15 9999 
50 76 


20 9999 

50 76 


25 9999 
68 96 


30 9999 

112 140 


85 9999 
118 134 


35 9999 

148 180 


ORAM 
♦ R 


tCAS(W) CAS# pulse «fdth(Mrt eye) 
♦twrtWAIT+tl -R 


CAS« 


\ 


CAS# 




25 9999 
81 108 


30 9999 

81 108 


25 9999 
108 .138 


30 9999 
81 108 


85 9999 
87 102 


35 9999 
108 138 


DRAM 

♦ Q 


tURP write to RAS# precharge 
+ti -U 
♦tBAK2BAK*twrtUAll-t1 -W 


UE« 


/ 
/ 


RAS# 
RAS# 




-30 9999 
13 42 
74 107 


-30 9999 
13 42 
74 107 


10 9999 
22 52 
180 222 


10 9999 
13 42 
136 171 


•30 9999 

17 40 
140 169 


10 9999 
22 52 

180 222 


DRAH 


tRUH RAS» to write hold time 
♦t1 *t\ -Q 


RAS# 


\ 


WE« 




9999 
52 82 


9999 
52 82 


15 9999 

70 102 


20 9999 
52 82 


9999 
54 78 


25 9999 
70 102 


DRAH 

+ Q 


tASR row address set-up time 
♦t1 ♦tl -t6+tHUX 
«tBAK2BAK^trfA^AIT -t6+tHUX 


row< 
row< 


RA5# 
RAS« 




9999 
16 73 
16 73 


9999 
16 73 
16 73 


9999 
34 93 
114 177 


9999 
16 73 
140 201 


9999 
20 71 
144 199 


9999 
34 93 
194 261 


DRAM 
+ tMUX 
♦ tMUX 


tRAH row address hold time 
♦P +t1 -0 
+P -m -Q 


RAS# 
RAS# 


\ 
\ 


colunrK 
column< 


15 9999 
23 55 
23 55 


15 9999 
23 55 
23 55 


15 9999 
32 65 
32 65 


20 9999 
23 55 
23 55 


20 9999 
25 51 
25 51 


25 9999 
32 65 
52 65 



Table C-5. DRAM Circuit Timing Parameters (Cont'd.) 



386 DRAM Controller 
TIMING CALCULATIOMS 



Chip 


Symbol 


10 Description 




From 




To 




Nin Max 
51C64-8 


Nin Max 
51C64-10 


Nin Max 
51C256-12 


Hin Max 
51C256-15 


Hin Max 
2164-15 


Hin Max 
51C256-20 


ORAM 
♦ R 

+ R 


tCP 
+ t1 

♦ t1 


CAS# precharge 

+ t1 ♦tl ♦tBAK2BAIC-R 

+t1 +t8AK2BAIC-R 


CAS# 
CAS« 


/ 
/ 


CAS« 
CASi 


\ 
\ 


10 9999 

143 172 
112 140 


10 9999 

143 172 
112 140 


10 9999 

268 306 
228 264 


10 9999 

205 236 
174 204 


25 9999 

211 230 
180 198 


10 9999 

268 306 
228 264 


DRAM 


tCRP CAS# to RAS« precharae 

-R 

+tBAIC2BAK-R 

♦tBAIC2BAK« 




CAS# 
CAS# 
CAS# 


/ 
/ 
/ 


RAS« 
RAS« 
SAS# 


\ 
\ 

\ 


-20 9999 
-12 12 
50 76 
50 76 


•20 9999 
■12 12 
50 76 
50 76 


-20 9999 
-12 12 
148 180 
148 180 


■20 9999 
-12 12 
112 140 
112 140 


•20 9999 
-6 6 
118 134 
118 134 


■20 9999 
■12 12 
148 180 
148 180 


ORAM 
♦R 


« tRCD 
♦ tl 

+t1 


RAS# to CAS« delay 

♦ tl -Q 

+t1 +11 Q 




RAS« 
RAS« 


\ 
\ 


CAS# 
CASi 


\ 
\ 


30 9999 
50 76 
81 108 


30 9999 
50 76 
81 108 


30 9999 
68 96 
108 138 


35 9999 
50 76 
81 108 


30 9999 
56 70 
87 102 


40 9999 
68 96 
108 138 


ORAM 

♦ R 

♦ R 


tASC 
♦ tl 
+tl 


column address set-up 

-P -tHUX 

♦tl -P -tHUX 




colijnn< 
column< 


CAS# 
CAS« 


V 


9999 
a 40 
39 72 


9999 
8 40 

39 72 


5 9999 
17 50 
57 92 


5 9999 
8 40 
39 72 


9999 
12 38 
43 70 


5 9999 
17 50 
57 92 


DRAM 
♦ tMUX 


tCAH 
♦P 


colunn address hold 
♦tl +11 +t1 


■R 










10 9999 


10 9999 


15 9999 


20 9999 


25 9999 


25 9999 



CAS# \ OramAddr< 85 119 85 119 112 149 85 119 87 115 112 149 
CAS« \ DraaiAddr< 54 87 54 87 72 107 54 87 56 83 72 107 



DRAM 
♦ tHUX 



tAR 
♦P 



column addr hold fr RAS« 
♦tl ♦tl +tl 



40 9999 40 9999 60 9999 70 9999 90 9999 80 9999 
♦tl +11 -Q 

RAS# \ DrainAddr< 147 183 147 183 192 233 147 183 149 179 192 233 
♦tl ttl -Q 

RAS# \ OramAddr< 147 183 147 183 192 233 147 183 149 179 192 233 



ORAM 


• tON 


• tXCVR 


-121 


DRAM 


* tOFf 


♦tXCVR 


♦ t12 


DRAM 


* tRAC 


-tXCVR 


-121 


DRAM 


* tCAC 


■tXCVR 


-121 



output buffer turn on 
♦trdUAIT +11 *t\ 



output buffer turn off 
♦tl ♦tBAK2BAK-R 



access time from RAS# 
♦trdWAIT +11 ♦tl 



access time from CAS# 
♦ trcJWAIT +tl ^tl 



20 9999 20 9999 25 9999 30 9999 85 9999 35 9999 
-R 

CAS« \ rd data<( 33 62 40 64 51 82 95 126 97 122 131 166 

20 9999 20 9999 20 9999 25 9999 30 9999 30 9999 

CAS# / wrt data< 84 153 82 146 191 267 146 217 148 213 191 267 

80 9999 100 9999 120 9999 150 9999 150 9999 200 9999 
♦tl +tl -Q 

RAS# \ rd data< 95 126 102 128 131 166 157 190 159 186 211 250 

20 9999 20 9999 25 9999 30 9999 85 9999 35 9999 
-R 

CAS« \ rd data< 33 62 40 64 51 82 95 126 97 122 131 166 



Table C-5. DRAM Circuit Timing Parameters (Cont'd.) 







386 DRAM Controller 
























TIMING C A L 


C U L A T 


1 


N S 
















Chip 


Synixji 


ID Description 


From 




To 




Hin Max 
51C64-8 


Nin Max 
51C64-10 


Min Max 
51C256-12 


Nin Nax 
51C256-15 


Nin Max 
2164-15 


Min Max 
51C256-20 


DRAH 
• tXCVR 


• tCAA 
•t21 


access time fr colunn adr 
♦trdWAIT +11 +11 


♦tl -P 

COluiffK 


-tHUX 
rd data< 


45 9999 
53 90 


55 9999 
60 92 


55 9999 
80 '120 


70 9999 
115 154 


85 9999 
115 154 


90 9999 
160 204 


ORAM 


tRSH(R) 
♦trdWAII 


RAS# hold time (rd cycle) 
♦tl +11 -R 


CAS# 


\ 


RAS« 


/ 


10 9999 
50 76 


10 9999 
50 76 


10 9999 
68 96 


10 9999 
112 140 


85 9999 
118 134 


10 9999 
148 180 


DRAH 
-tXCVR 


tRCS 
-121 


read command set-up time 
♦trdWAIT +tl +t1 


♦tl 

RAS# 


♦tl 
\ 


-Q 
rd data< 


9999 
95 126 


09999 
102 128 


9999 
131 166 


9999 
157 190 


9999 
159 186 


9999 
211 250 


DRAM 
♦Q 


tCAR 
-^trdUAll 


colunn address to RAS« 
♦t1 ttl ♦tl 


-p twx 

coluin< RASf 




45 9999 
70 104 


55 9999 
70 104 


55 9999 
97 134 


70 9999 
132 168 


85 9999 
136 166 


90 9999 
177 218 


ORAM 
*W 


tRCH 
♦ t1 


read com hold ref to CAS# 
♦tl ♦tBAK2BAIC-R 


CASf 




UE« 




9999 
114 146 


9999 
114 146 


9999 

230 270 


9999 
176 210 


5 9999 
178 206 


9999 
230 270 


DRAM 

♦W 


tRRH 
♦t1 


read com hold ref to RAS# 
♦tl ♦tBAK2BAK-Q 


RAS« 




yE« 




10 9999 
114 146 


10 9999 
114 146 


10 9999 
230 270 


10 9999 
176 210 


20 9999 
178 206 


10 9999 

230 270 


DRAM 


tRSH(U} RAS# hold time (urt cycl) 
♦twrtWAIT+tl -R 


CAS« 




RA5« 




35 9999 

81 108 


35 9999 
81 108 


25 9999 
108 138 


30 9999 
81 108 


85 9999 
87 102 


35 9999 
108 138 


DRAM 
♦Q 


tRUL 
*twrtUAi 


write conntand to RAS# 
T*t1 +t1 -W 


UE« 




RAS« 




25 9999 
106 138 


30 9999 
106 138 


25 9099 
142 178 


30 9999 
106 138 


40 9999 
110 136 


35 9999 
142 178 


DRAM 
♦R 


tCWL write command to CAS# 
♦twrtUAIT*t1 +t1 -W 


WE« 




CAS# 




25 9999 
106 138 


30 9999 

106 138 


25 9999 
142 178 


30 9999 
106 138 


40 9999 
110 136 


35 9999 
142 178 


DRAM 


tup 

♦ t1 


write command pulse width 
♦tl +11 -w 


WE« 




UE« 




20 9999 
77 112 


20 9999 
77 112 


20 9999 
104 142 


25 9999 
77 112 


30 9999 
77 112 


30 9999 
104 142 


DRAH 
♦ R 


tucs 

+ t1 


write command set-up time 
-U 


WE# 




CAS# 




9999 
13 42 


9999 
13 42 


9999 
22 52 


9999 
13 42 


-10 9999 
17 40 


9999 
22 52 


ORAM 


tUCH 
+ t1 


write command hold time 
♦ tl -R 


CAS# 




UE# 




25 9999 
52 82 


30 9999 
52 82 


25 9999 
70 102 


30 9999 
52 82 


30 9999 
54 78 


35 9999 
70 102 
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